This is an archive of the discontinued LLVM Phabricator instance.

ComputeKnownBits: be a bit smarter about ADDs
ClosedPublic

Authored by escha on Jun 17 2015, 11:53 AM.

Details

Summary

If our two inputs have known top-zero bit counts M and N, we trivially know that the output cannot have any bits set in the top (min(M, N)-1) bits, since nothing could carry past that point.

Diff Detail

Event Timeline

escha updated this revision to Diff 27857.Jun 17 2015, 11:53 AM
escha retitled this revision from to ComputeKnownBits: be a bit smarter about ADDs.
escha updated this object.
escha edited the test plan for this revision. (Show Details)
escha added a reviewer: resistor.
escha set the repository for this revision to rL LLVM.
escha added a subscriber: Unknown Object (MLST).
escha updated this revision to Diff 27859.Jun 17 2015, 12:59 PM

Added a test on x86 that utilizes this feature of ComputeKnownBits.

escha updated this revision to Diff 27861.Jun 17 2015, 1:08 PM

Fix one test that broke as a result of this, because LLVM decided to shrink the constant.

escha updated this revision to Diff 27867.Jun 17 2015, 1:34 PM

Fix one last test now that I've run all of the CodeGen tests.

resistor edited edge metadata.Jun 27 2015, 9:25 PM

Is there any hope of fixing the regression on test/CodeGen/X86/win64_frame.ll?

escha added a comment.Jun 27 2015, 9:27 PM

I really can't think of anything without going into x86-specific backend hacks (or other larger-scale changes in the constant optimization bits of the backend) :-/

LLVM tries to aggressively shrink constants in the general case, and unfortunately it hurts here... but I imagine it already hurts in a lot of other cases, this optimization just exposes one more.

I really can't think of anything without going into x86-specific backend hacks (or other larger-scale changes in the constant optimization bits of the backend) :-/

LLVM tries to aggressively shrink constants in the general case, and unfortunately it hurts here... but I imagine it already hurts in a lot of other cases, this optimization just exposes one more.

I agree, and we should fix this. The code that generates 'andq $-16, %rax' should more-generally match $34359738352 too as -16 by checking that the upper bits of the incoming value are known to be zero.

escha added a comment.Jul 7 2015, 8:45 AM

Is this patch okay? Are there any other concerns?

resistor accepted this revision.Jul 10 2015, 11:08 AM
resistor edited edge metadata.

Patch LGTM. Can you file a PR for X86?

This revision is now accepted and ready to land.Jul 10 2015, 11:08 AM
escha closed this revision.Jul 10 2015, 11:29 AM