Commit Graph

18 Commits

Author SHA1 Message Date
Sanjay Patel a194b2d2ff [InstCombine] fold fneg into constant operand of fmul/fdiv
This accounts for the missing IR fold noted in D50195. We don't need any fast-math to enable the negation transform. 
FP negation can always be folded into an fmul/fdiv constant to eliminate the fneg.

I've limited this to one-use to ensure that we are eliminating an instruction rather than replacing fneg by a 
potentially expensive fdiv or fmul.

Differential Revision: https://reviews.llvm.org/D50417

llvm-svn: 339248
2018-08-08 14:29:08 +00:00
Michael Berg 2e60ad2e58 [NFC] adding tests for Y - (X + Y) --> -X
llvm-svn: 339197
2018-08-07 22:52:57 +00:00
Sanjay Patel ceb595b04e [InstCombine] don't negate constant expression with fsub (PR37605)
X + (-C) would be transformed back into X - C, so infinite loop:
https://bugs.llvm.org/show_bug.cgi?id=37605

llvm-svn: 333610
2018-05-30 23:55:12 +00:00
Sanjay Patel ff98682c9c [InstCombine] limit X - (cast(-Y) --> X + cast(Y) with hasOneUse()
llvm-svn: 329821
2018-04-11 15:57:18 +00:00
Sanjay Patel de9f7458a4 [InstCombine] add/move tests for fsub folds; NFC
There are a pair of folds that try to merge fneg into fsub
with an intervening cast, but as shown in the FIXME tests,
they can create extra instructions.

llvm-svn: 329501
2018-04-07 14:07:58 +00:00
Sanjay Patel a9ca709011 [InstCombine] limit nsz: -(X - Y) --> Y - X to hasOneUse()
As noted in the post-commit discussion for r329350, we shouldn't
generally assume that fsub is the same cost as fneg.

llvm-svn: 329429
2018-04-06 17:24:08 +00:00
Sanjay Patel a6823f0e67 [InstCombine] add test for fsub+fneg with extra use; NFC
llvm-svn: 329418
2018-04-06 16:30:52 +00:00
Sanjay Patel 04683de82f [InstCombine] FP: Z - (X - Y) --> Z + (Y - X)
This restores what was lost with rL73243 but without
re-introducing the bug that was present in the old code.

Note that we already have these transforms if the ops are 
marked 'fast' (and I assume that's happening somewhere in
the code added with rL170471), but we clearly don't need 
all of 'fast' for these transforms.

llvm-svn: 329362
2018-04-05 23:21:15 +00:00
Sanjay Patel 715ba65317 [InstCombine] add FP tests for Z - (X - Y); NFC
A fold for this pattern was removed at rL73243 to fix PR4374:
https://bugs.llvm.org/show_bug.cgi?id=4374
...and apparently there were no tests that went with that fold.

llvm-svn: 329360
2018-04-05 22:56:54 +00:00
Sanjay Patel 03e2526728 [InstCombine] nsz: -(X - Y) --> Y - X
This restores part of the fold that was removed with rL73243 (PR4374).

llvm-svn: 329350
2018-04-05 21:37:17 +00:00
Sanjay Patel 37248d35c3 [InstCombine] add test for fneg+fsub with nsz; NFC
There used to be a fold that would handle this case more generally,
but it was removed at rL73243 to fix PR4374:
https://bugs.llvm.org/show_bug.cgi?id=4374

llvm-svn: 329322
2018-04-05 17:40:51 +00:00
Sanjay Patel deaf4f354e [InstCombine] use pattern matchers for fsub --> fadd folds
This allows folding for vectors with undef elements.

llvm-svn: 329316
2018-04-05 17:06:45 +00:00
Sanjay Patel 7becb3ae4b [InstCombine] add tests for fsub --> fadd; NFC
llvm-svn: 329313
2018-04-05 16:51:09 +00:00
Sanjay Patel 4222716822 [InstSimplify] fp_binop X, undef --> NaN
The variable operand could be NaN, so it's always safe to propagate NaN.

llvm-svn: 327212
2018-03-10 16:51:28 +00:00
Sanjay Patel e5606b4fa5 [ConstantFold] fp_binop AnyConstant, undef --> NaN
With the updated LangRef ( D44216 / rL327138 ) in place, we can proceed with more constant folding.

I'm intentionally taking the conservative path here: no matter what the constant or the FMF, we can 
always fold to NaN. This is because the undef operand can be chosen as NaN, and in our simplified 
default FP env, nothing else happens - NaN just propagates to the result. If we find some way/need 
to propagate undef instead, that can be added subsequently.

The tests show that we always choose the same quiet NaN constant (0x7FF8000000000000 in IR text). 
There were suggestions to improve that with a 'NaN' string token or not always print a 64-bit hex 
value, but those are independent changes. We might also consider setting/propagating the payload of 
NaN constants as an enhancement.

Differential Revision: https://reviews.llvm.org/D44308

llvm-svn: 327208
2018-03-10 15:56:25 +00:00
Sanjay Patel faf9b0f322 [InstCombine] regenerate checks; NFC
We may not need any of these tests after rL327012, but leaving 
them here for now until that's confirmed.

llvm-svn: 327014
2018-03-08 15:46:38 +00:00
Matt Arsenault 02907f3039 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
2017-04-24 17:24:37 +00:00
Bill Wendling 3fbf36d0b4 Reduce fsub-fadd.ll and merge it into fsub-fsub.ll. Rename fsub-fsub.ll to
fsub.ll and FileCheckify it.

llvm-svn: 93669
2010-01-17 00:21:21 +00:00