xref: /aosp_15_r20/external/llvm/test/CodeGen/X86/dag-optnone.ll (revision 9880d6810fe72a1726cb53787c6711e909410d58)
1*9880d681SAndroid Build Coastguard Worker; RUN: llc < %s -mtriple=x86_64-pc-win32 -O0 -mattr=+avx | FileCheck %s
2*9880d681SAndroid Build Coastguard Worker
3*9880d681SAndroid Build Coastguard Worker; Background:
4*9880d681SAndroid Build Coastguard Worker; If fast-isel bails out to normal selection, then the DAG combiner will run,
5*9880d681SAndroid Build Coastguard Worker; even at -O0. In principle this should not happen (those are optimizations,
6*9880d681SAndroid Build Coastguard Worker; and we said -O0) but as a practical matter there are some instruction
7*9880d681SAndroid Build Coastguard Worker; selection patterns that depend on the legalizations and transforms that the
8*9880d681SAndroid Build Coastguard Worker; DAG combiner does.
9*9880d681SAndroid Build Coastguard Worker;
10*9880d681SAndroid Build Coastguard Worker; The 'optnone' attribute implicitly sets -O0 and fast-isel for the function.
11*9880d681SAndroid Build Coastguard Worker; The DAG combiner was disabled for 'optnone' (but not -O0) by r221168, then
12*9880d681SAndroid Build Coastguard Worker; re-enabled in r233153 because of problems with instruction selection patterns
13*9880d681SAndroid Build Coastguard Worker; mentioned above. (Note: because 'optnone' is supposed to match -O0, r221168
14*9880d681SAndroid Build Coastguard Worker; really should have disabled the combiner for both.)
15*9880d681SAndroid Build Coastguard Worker;
16*9880d681SAndroid Build Coastguard Worker; If instruction selection eventually becomes smart enough to run without DAG
17*9880d681SAndroid Build Coastguard Worker; combiner, then the combiner can be turned off for -O0 (not just 'optnone')
18*9880d681SAndroid Build Coastguard Worker; and this test can go away. (To be replaced by a different test that verifies
19*9880d681SAndroid Build Coastguard Worker; the DAG combiner does *not* run at -O0 or for 'optnone' functions.)
20*9880d681SAndroid Build Coastguard Worker;
21*9880d681SAndroid Build Coastguard Worker; In the meantime, this test wants to make sure the combiner stays enabled for
22*9880d681SAndroid Build Coastguard Worker; 'optnone' functions, just as it is for -O0.
23*9880d681SAndroid Build Coastguard Worker
24*9880d681SAndroid Build Coastguard Worker
25*9880d681SAndroid Build Coastguard Worker; The test cases @foo[WithOptnone] prove that the same DAG combine happens
26*9880d681SAndroid Build Coastguard Worker; with -O0 and with 'optnone' set.  To prove this, we use a Windows triple to
27*9880d681SAndroid Build Coastguard Worker; cause fast-isel to bail out (because something about the calling convention
28*9880d681SAndroid Build Coastguard Worker; is not handled in fast-isel).  Then we have a repeated fadd that can be
29*9880d681SAndroid Build Coastguard Worker; combined into an fmul.  We show that this happens in both the non-optnone
30*9880d681SAndroid Build Coastguard Worker; function and the optnone function.
31*9880d681SAndroid Build Coastguard Worker
32*9880d681SAndroid Build Coastguard Workerdefine float @foo(float %x) #0 {
33*9880d681SAndroid Build Coastguard Workerentry:
34*9880d681SAndroid Build Coastguard Worker  %add = fadd fast float %x, %x
35*9880d681SAndroid Build Coastguard Worker  %add1 = fadd fast float %add, %x
36*9880d681SAndroid Build Coastguard Worker  ret float %add1
37*9880d681SAndroid Build Coastguard Worker}
38*9880d681SAndroid Build Coastguard Worker
39*9880d681SAndroid Build Coastguard Worker; CHECK-LABEL: @foo
40*9880d681SAndroid Build Coastguard Worker; CHECK-NOT:   add
41*9880d681SAndroid Build Coastguard Worker; CHECK:       mul
42*9880d681SAndroid Build Coastguard Worker; CHECK-NEXT:  ret
43*9880d681SAndroid Build Coastguard Worker
44*9880d681SAndroid Build Coastguard Workerdefine float @fooWithOptnone(float %x) #1 {
45*9880d681SAndroid Build Coastguard Workerentry:
46*9880d681SAndroid Build Coastguard Worker  %add = fadd fast float %x, %x
47*9880d681SAndroid Build Coastguard Worker  %add1 = fadd fast float %add, %x
48*9880d681SAndroid Build Coastguard Worker  ret float %add1
49*9880d681SAndroid Build Coastguard Worker}
50*9880d681SAndroid Build Coastguard Worker
51*9880d681SAndroid Build Coastguard Worker; CHECK-LABEL: @fooWithOptnone
52*9880d681SAndroid Build Coastguard Worker; CHECK-NOT:   add
53*9880d681SAndroid Build Coastguard Worker; CHECK:       mul
54*9880d681SAndroid Build Coastguard Worker; CHECK-NEXT:  ret
55*9880d681SAndroid Build Coastguard Worker
56*9880d681SAndroid Build Coastguard Worker
57*9880d681SAndroid Build Coastguard Worker; The test case @bar is derived from an instruction selection failure case
58*9880d681SAndroid Build Coastguard Worker; that was solved by r233153. It depends on -mattr=+avx.
59*9880d681SAndroid Build Coastguard Worker; Really all we're trying to prove is that it doesn't crash any more.
60*9880d681SAndroid Build Coastguard Worker
61*9880d681SAndroid Build Coastguard Worker@id84 = common global <16 x i32> zeroinitializer, align 64
62*9880d681SAndroid Build Coastguard Worker
63*9880d681SAndroid Build Coastguard Workerdefine void @bar() #1 {
64*9880d681SAndroid Build Coastguard Workerentry:
65*9880d681SAndroid Build Coastguard Worker  %id83 = alloca <16 x i8>, align 16
66*9880d681SAndroid Build Coastguard Worker  %0 = load <16 x i32>, <16 x i32>* @id84, align 64
67*9880d681SAndroid Build Coastguard Worker  %conv = trunc <16 x i32> %0 to <16 x i8>
68*9880d681SAndroid Build Coastguard Worker  store <16 x i8> %conv, <16 x i8>* %id83, align 16
69*9880d681SAndroid Build Coastguard Worker  ret void
70*9880d681SAndroid Build Coastguard Worker}
71*9880d681SAndroid Build Coastguard Worker
72*9880d681SAndroid Build Coastguard Workerattributes #0 = { "unsafe-fp-math"="true" }
73*9880d681SAndroid Build Coastguard Workerattributes #1 = { noinline optnone "unsafe-fp-math"="true" }
74