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.
Details
Diff Detail
Event Timeline
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 | ||
---|---|---|
1935–1936 | 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. |
The code change LGTM.
The changes inspires two thoughts:
- As we've discussed off list and Chandler mentioned, we need to
investigate profitability of various invariant condition propagation
schemes.
- 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
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.