don't hoist FP additions into unconditional adds + selects. This

could theoretically introduce a trap, but is also a performance issue.
This speeds up ptrdist/ks by 8%.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45533 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Chris Lattner 2008-01-03 07:25:26 +00:00
parent 76327d9cf5
commit 3d73bce2d0
2 changed files with 28 additions and 0 deletions

View File

@ -372,6 +372,8 @@ static bool DominatesMergePoint(Value *V, BasicBlock *BB,
case Instruction::AShr:
case Instruction::ICmp:
case Instruction::FCmp:
if (I->getOperand(0)->getType()->isFPOrFPVector())
return false; // FP arithmetic might trap.
break; // These are all cheap and non-trapping instructions.
}

View File

@ -0,0 +1,26 @@
; The phi should not be eliminated in this case, because the fp op could trap.
; RUN: llvm-as < %s | opt -simplifycfg | llvm-dis | grep {= phi double}
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128"
target triple = "i686-apple-darwin8"
@G = weak global double 0.000000e+00, align 8 ; <double*> [#uses=2]
define void @test(i32 %X, i32 %Y, double %Z) {
entry:
%"alloca point" = bitcast i32 0 to i32 ; <i32> [#uses=0]
%tmp = load double* @G, align 8 ; <double> [#uses=2]
%tmp3 = icmp eq i32 %X, %Y ; <i1> [#uses=1]
%tmp34 = zext i1 %tmp3 to i8 ; <i8> [#uses=1]
%toBool = icmp ne i8 %tmp34, 0 ; <i1> [#uses=1]
br i1 %toBool, label %cond_true, label %cond_next
cond_true: ; preds = %entry
%tmp7 = add double %tmp, %Z ; <double> [#uses=1]
br label %cond_next
cond_next: ; preds = %cond_true, %entry
%F.0 = phi double [ %tmp, %entry ], [ %tmp7, %cond_true ] ; <double> [#uses=1]
store double %F.0, double* @G, align 8
ret void
}