Normally an 'optnone' function goes through fast-isel, which does not

call DAGCombiner. But we ran into a case (on Windows) where the
calling convention causes argument lowering to bail out of fast-isel,
and we end up in CodeGenAndEmitDAG() which does run DAGCombiner.
So, we need to make DAGCombiner check for 'optnone' after all.

Commit includes the test that found this, plus another one that got
missed in the original optnone work.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221168 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Paul Robinson
2014-11-03 18:19:26 +00:00
parent 5e84760dde
commit c3e82bf9f5
3 changed files with 177 additions and 0 deletions

View File

@@ -0,0 +1,35 @@
; RUN: llc < %s -mcpu=corei7 -march=x86-64 -mattr=+sse2 | FileCheck %s
; Verify that floating-point operations inside 'optnone' functions
; are not optimized even if unsafe-fp-math is set.
define float @foo(float %x) #0 {
entry:
%add = fadd fast float %x, %x
%add1 = fadd fast float %add, %x
ret float %add1
}
; CHECK-LABEL: @foo
; CHECK-NOT: add
; CHECK: mul
; CHECK-NOT: add
; CHECK: ret
define float @fooWithOptnone(float %x) #1 {
entry:
%add = fadd fast float %x, %x
%add1 = fadd fast float %add, %x
ret float %add1
}
; CHECK-LABEL: @fooWithOptnone
; CHECK-NOT: mul
; CHECK: add
; CHECK-NOT: mul
; CHECK: add
; CHECK-NOT: mul
; CHECK: ret
attributes #0 = { "unsafe-fp-math"="true" }
attributes #1 = { noinline optnone "unsafe-fp-math"="true" }