This is an archive of the discontinued LLVM Phabricator instance.

[InstCombine] Teach SimplifyDemandedUseBits that adding or subtractings 0s from every bit below the highest demanded bit can be simplified
ClosedPublic

Authored by craig.topper on Mar 19 2017, 1:12 AM.

Details

Summary

If we are adding/subtractings 0s below the highest demanded bit we can just use the other operand and remove the operation.

My primary motivation is observing that we can call ShrinkDemandedConstant for the add/sub and create a 0 constant, rather than removing the add completely. In the case I saw, we modified the constant on an add instruction to a 0, but the add is not put into the worklist. So we didn't revisit it until the next InstCombine iteration. This caused an IR modification to remove add and a subsequent iteration to be ran.

With this change we get bypass the add in the first iteration and prevent the second iteration from changing anything.

Not sure how to test this because we do eventually optimize it. Is there any way to bound instcombine iterations from the command line?

Diff Detail

Event Timeline

craig.topper created this revision.Mar 19 2017, 1:12 AM
spatel edited edge metadata.Mar 21 2017, 4:30 PM
spatel added a subscriber: efriedma.

In D31094, @efriedma suggested a debug counter to make this visible in a test.

Yeah I saw that. Should we add a debug counter around the top level worklist loop? The semantics of the "skip" part of the counter wouldn't make sense though.

Found another way of testing this particular transform.

spatel accepted this revision.Apr 12 2017, 7:39 AM

LGTM.

This revision is now accepted and ready to land.Apr 12 2017, 7:39 AM
spatel added inline comments.Apr 12 2017, 7:41 AM
test/Transforms/InstCombine/and2.ll
125 ↗(On Diff #93705)

This comment (copy/pasted below too) confused me. Shouldn't it be:
"The add in this test is unnecessary because the LSBs of the RHS are 0 and we do not consume those bits."

craig.topper added inline comments.Apr 12 2017, 9:36 AM
test/Transforms/InstCombine/and2.ll
125 ↗(On Diff #93705)

The comment is bad given the immediate used on the and. The optimization is valid even if the and immediate is 255. I'll try to clarify it.

This revision was automatically updated to reflect the committed changes.