If the branch that leads to the PHI node and the Select instruction
depend on correlated conditions, we might be able to directly use the
corresponding value from the Select instruction as the incoming value
for the PHI node, allowing later removal of the select instruction.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
FWIW, this helps with an optimization problem we hit with the rust compiler:
https://github.com/rust-lang/rust/issues/24489
Seems like a reasonable approach. A couple of small comments, but once those are addressed, should be easy to sign off on.
lib/Transforms/Scalar/CorrelatedValuePropagation.cpp | ||
---|---|---|
115 ↗ | (On Diff #23899) | I don't understand why we need the vector type check? Is this a limitation of LVI? If so, it should be pushed inside the LVI function being called. (i.e. returning Unknown for a vector type is perfectly reasonable) |
118 ↗ | (On Diff #23899) | I wonder whether a wrapper function on LVI which just take an ICmpInst would be more clear here. The comparison of against true is slightly opaque at first. |
test/Transforms/CorrelatedValuePropagation/select.ll | ||
8 ↗ | (On Diff #23899) | A few more tests would be good. In particular:
|
lib/Transforms/Scalar/CorrelatedValuePropagation.cpp | ||
---|---|---|
118 ↗ | (On Diff #23899) | Actually, I can just use getConstantOnEdge, which is easier to read and better at handling the vector types. Not sure what made me think that I could not use that. With the predicate approach, the false case matches all vectors except for the one with all ones, which is why I had excluded the vector types. I'm currently struggling at coming up with a test for the vector types though. |
Updated the patch to use getConstantOnEdge to improve readability. Added a
simpler test case without a loop and a negative test case. LVI doesn't support
vector types yet, so there's no test for that, but I left a note that support
for vector types may be added later.