This is an archive of the discontinued LLVM Phabricator instance.

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

Authored by lebedev.ri on Aug 17 2019, 2:50 PM.

Details

Summary

Finally, the fold i was looking forward to :)

The legality check is muddy, i doubt i've groked the full generalization,
but it handles all the cases i care about, and can come up with:
https://rise4fun.com/Alive/26j

I.e. we can perform the fold if any of the following is true:

  • The shift amount is either zero or one less than widest bitwidth
  • Either of the values being shifted has at most lowest bit set
  • The value that is being shifted by shl (which is not truncated) should have no less leading zeros than the total shift amount;
  • The value that is being shifted by lshr (which is truncated) should have no less leading zeros than the widest bit width minus total shift amount minus one

I strongly suspect there is some better generalization, but i'm not aware of it as of right now.
For now i also avoided using actual computeKnownBits(), but restricted it to constants.

Diff Detail

Event Timeline

lebedev.ri created this revision.Aug 17 2019, 2:50 PM

Cleanup diff by precommitting NFC cleanup,

Does this show up in bootstrap/test suite?

Rare folds with big pattern matching should go to AgressiveInstCombine.

llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp
3462

Use ´WidestBitWidth´

3474

Hoist it

3510

Replace 63 with WidestBitWidth - 1?

Does this show up in bootstrap/test suite?

I have not checked this particular pattern extensions,
but i know it does appear in hotspots in my code which is why i'm trying to add these folds :S

Rare folds with big pattern matching should go to AgressiveInstCombine.

Yes it is a concern indeed, but we've had this disscussion in https://reviews.llvm.org/D64512#1587640 already, this isn't much different.

A few clean-ups noted inline.

If I'm reading it correctly, this is more complicated than it could be only to support arbitrary vector constants. Do we have any evidence that says we need that support?

We've come this far on this series of patches without raising that question, so I'm not going to object to this particular patch now. But I think we should keep the code simpler unless we know there's a reason to handle the arbitrary vector constant pattern. It seems too rare to me to warrant this much effort.

llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp
3467

I don't see the value of the 'Check' lambda. Just do this check inline?

3468

"Cst" is ambiguous (I always read that as "Cast"). "MatchCmpInteger"?

3474

Move this local variable declaration/assignment up, so it can be used in lines 3383/3384?

3500

typo: 'the the'

3503
3509

We prefer "auto *" based on current guidelines.

3510

Generalize "63" to "WideWidth - 1"?

A few clean-ups noted inline.

If I'm reading it correctly, this is more complicated than it could be only to support arbitrary vector constants. Do we have any evidence that says we need that support?

We've come this far on this series of patches without raising that question, so I'm not going to object to this particular patch now. But I think we should keep the code simpler unless we know there's a reason to handle the arbitrary vector constant pattern. It seems too rare to me to warrant this much effort.

Indeed, non-splat support is ugly here, and incomplete still.
I don't have any evidence, and furthermore i only need scalar support from this, so i will happily cripple it.

lebedev.ri marked 12 inline comments as done.

Rebased, addressed review notes, pessimized vectors even more.

llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp
3467

It will result in ugly cascade of if's - if one of preconditions does not match we can't just abort,
some next precondition can still match and thus allow the fold.
I believe it is better to keep lambda here.

3503

Whoops, this was not intentional.

spatel accepted this revision.Aug 28 2019, 12:21 PM

LGTM - still complicated, but easier to read without the ConstExpr logic. :)

llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp
3472–3474

That's a confusing name for the common (scalar) case since that's not a splat. "NewShAmtC" ?

This revision is now accepted and ready to land.Aug 28 2019, 12:21 PM

LGTM

Thank you for the review!

still complicated, but easier to read without the ConstExpr logic. :)

Yeah :/ I'm likely missing some generalization.

This revision was automatically updated to reflect the committed changes.