From 02907f30397129dbebb2b633135c638a25c99463 Mon Sep 17 00:00:00 2001 From: Matt Arsenault Date: Mon, 24 Apr 2017 17:24:37 +0000 Subject: InstCombine: Fix assert when reassociating fsub with undef There is logic to track the expected number of instructions produced. It thought in this case an instruction would be necessary to negate the result, but here it folded into a ConstantExpr fneg when the non-undef value operand was cancelled out by the second fsub. I'm not sure why we don't fold constant FP ops with undef currently, but I think that would also avoid this problem. llvm-svn: 301199 --- llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'llvm/lib/Transforms') diff --git a/llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp b/llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp index 05f34e9eaa0..e946acf84f5 100644 --- a/llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp +++ b/llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp @@ -794,6 +794,11 @@ unsigned FAddCombine::calcInstrNumber(const AddendVect &Opnds) { if (Opnd->isConstant()) continue; + // The constant check above is really for a few special constant + // coefficients. + if (isa(Opnd->getSymVal())) + continue; + const FAddendCoef &CE = Opnd->getCoef(); if (CE.isMinusOne() || CE.isMinusTwo()) NegOpndNum++; -- cgit v1.2.3