This is an archive of the discontinued LLVM Phabricator instance.

[InstCombine] Shift amount reassociation in bittest: trunc-of-shl (PR42399)
ClosedPublic

Authored by lebedev.ri on Aug 10 2019, 12:40 PM.

Details

Summary

This is continuation of D63829 / https://bugs.llvm.org/show_bug.cgi?id=42399

I thought naive pattern would solve my issue, but nope, it involved truncation,
thus more folds needed.. This isn't really the fold i'm interested in,
i need trunc-of-lshr, but i'we decided to start with shl because it's simpler.

In this case, no extra legality checks are needed:
https://rise4fun.com/Alive/CAb

We should be careful about not increasing instruction count,
since we need to produce zext because and is done in wider type.

Diff Detail

Event Timeline

lebedev.ri created this revision.Aug 10 2019, 12:40 PM
spatel added inline comments.Aug 15 2019, 9:54 AM
llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp
3314–3320

Can we make the change to use Instruction*/m_Instruction independently (ie as a pre-commit) of this patch?
(I'd be fine without requiring a weird ConstExpr test to prove the diff if that was a possibility.)

3372

Extra period at end.

lebedev.ri added inline comments.Aug 15 2019, 10:11 AM
llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp
3314–3320

I actually already did that in rL368554 to fix https://bugs.llvm.org/show_bug.cgi?id=42962
I just need to rebase this, hold on..

lebedev.ri marked 3 inline comments as done.

Rebased, thanks for taking a look!

spatel added inline comments.Aug 15 2019, 3:00 PM
llvm/test/Transforms/InstCombine/shift-amount-reassociation-in-bittest-with-truncation-shl.ll
414

Please explain and/or add a comment here.
If we leave the add constant as 1, this gets simplified away completely with this patch? Why doesn't it happen with 32?
Do we already have a test that covers the case for the original test (with add of 1)?

lebedev.ri marked 2 inline comments as done.Aug 15 2019, 11:19 PM

Thanks for taking a look!

llvm/test/Transforms/InstCombine/shift-amount-reassociation-in-bittest-with-truncation-shl.ll
414

With %t2 = add i32 %len, 1 the total shift is ((32-len)+(len+1))==33.
The widest type here is i64, and 33 is a valid shift amount there.
But since one of the values being shifted is i32, the result can be constant-folded to false
since you will effectively shift-out all the bits.
https://rise4fun.com/Alive/kk1

With 32 here, the total shift amount will be 64, which is not okay for i64.
But that would already imply UB, and we should be folding it into undef
https://rise4fun.com/Alive/Tzn

I'm trying to keep changes reviewable, so i did not get to that part yet.

The @t9_oneuse5 gets constant-folded too, so there is some coverage.

spatel accepted this revision.Aug 16 2019, 7:02 AM

LGTM

llvm/test/Transforms/InstCombine/shift-amount-reassociation-in-bittest-with-truncation-shl.ll
414

Ok - thanks for the explanation.

This revision is now accepted and ready to land.Aug 16 2019, 7:02 AM
lebedev.ri marked an inline comment as done.Aug 16 2019, 7:55 AM

Thank you for the review.
I'll follow-up here with a patch for trunc-of-lshr (finally, the one i need).

This revision was automatically updated to reflect the committed changes.