Move the binary FNEG combine so that it also applies to unary FNeg.
Details
Diff Detail
Event Timeline
llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp | ||
---|---|---|
1625 | If you started with a unary fneg, shouldn't we end up with a unary fneg? |
llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp | ||
---|---|---|
1625 | So this combine actually covers both unary and binary FNeg. m_FNeg(X) will match an FSub(-0.0,X). The end goal is that both will end up producing an unary FNeg. But, yeah, I see what you're saying. I could dispatch on the operator type for now, but it would be code to clean up later. I suppose the BinaryOperator will have to be switched to an UnaryOperator in the future anyway, so I'm not sure how much work I'm saving. Just thinking aloud, I don't have a preference... |
llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp | ||
---|---|---|
1625 | Thinking about this some more, you’re correct. It’s not safe to turn a unary FNeg into a binary FNeg. I was thinking about this as a short term solution, but we should play it safe in case this does not get updated. I’ll update the patch... |
Fix the Unary/Binary operator issue.
Also note that this change will require UnaryOperator::CreateFNegFMF(...) from D62521, so cannot be committed until that is complete.
Forgot to update the tests.
Will hold off on making any other corrections until D62521 has landed...
It's actually covered by the new @unary_neg_trunc_op1_extra_use and existing @neg_trunc_op1_extra_use tests. I missed that each was producing an extra instruction in my Diff before the hasOneUse() change. I had failed to copy over that check to the new code from the old BinaryOperator code above this.
Also, I just noticed I failed to add context to this patch. Will do so now...
llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp | ||
---|---|---|
1535 | This is the check that guarded the old BinaryOperator-only combine. |
If you started with a unary fneg, shouldn't we end up with a unary fneg?