This is an archive of the discontinued LLVM Phabricator instance.

Check for all known bits on ret in InstCombine
ClosedPublic

Authored by hfinkel on Jul 17 2014, 10:58 AM.

Details

Reviewers
chandlerc
Summary

From a combination of invariants (and perhaps through other means), it is possible that all bits of a return value might be known. Currently, InstCombine does not check for this (which is understandable given assumptions of constant propagation), but means that we'd miss simple cases where invariants are involved.

Diff Detail

Event Timeline

hfinkel updated this revision to Diff 11597.Jul 17 2014, 10:58 AM
hfinkel retitled this revision from to Check for all known bits on ret in InstCombine.
hfinkel updated this object.
hfinkel edited the test plan for this revision. (Show Details)
hfinkel added a reviewer: chandlerc.
hfinkel added a subscriber: Unknown Object (MLST).
chandlerc accepted this revision.Jul 17 2014, 12:06 PM
chandlerc edited edge metadata.

This patch seems trivially fine once we sort out invariants. However, I wonder about doing something more comprehensive. No need to wait for that to make basic improvements here, but something to think about.

lib/Transforms/InstCombine/InstructionCombining.cpp
1938–1939

I wonder if it makes sense to do something somewhat more pervasive by replacing all uses of a value? Essentially, an invariant constant propagation pass.

This revision is now accepted and ready to land.Jul 17 2014, 12:06 PM
hfinkel updated this revision to Diff 11700.Jul 20 2014, 12:00 PM
hfinkel edited edge metadata.

Renamed to llvm.assume.

reames added a subscriber: reames.Jul 22 2014, 10:20 AM

The code change LGTM.

The changes inspires two thoughts:

  1. As we've discussed off list and Chandler mentioned, we need to

investigate profitability of various invariant condition propagation
schemes.

  1. When do we remove a llvm.assume? In your test case, you had an

assume which (after the transform) retained a condition about an
otherwise used value (%a). This seems like an obvious case to remove
since we've gotten all the benefit we can from it. Are there other
cases like this we should implement?

p.s. Do you have a wiki or notes page somewhere where we can track
potential enhancements? I worry large parts are getting lost in all the
various review threads.

Philip

hfinkel updated this revision to Diff 11935.Jul 27 2014, 11:27 PM

Rebased (perhaps no change in the limited-context diff).

hfinkel closed this revision.Sep 7 2014, 2:39 PM

r217346.