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