In case we do not know what the condition is in an unswitched loop, but we know its definitely NOT a known constant. We can perform simplifcations based on this information. More specifically we can simplify comparison instructions with the cond...
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/Transforms/Scalar/LoopUnswitch.cpp | ||
---|---|---|
1395 ↗ | (On Diff #89079) | Val is going to be a ConstantInt, as its used by ICmpInst, I will add an assert though =). |
lib/Transforms/Scalar/LoopUnswitch.cpp | ||
---|---|---|
1395 ↗ | (On Diff #89079) | It will be a Constant of integer type... but that's not the same thing as a ConstantInt. (For example ptrtoint i32* @g to i64. is a Constant of integer type.) |
lib/Transforms/Scalar/LoopUnswitch.cpp | ||
---|---|---|
1395 ↗ | (On Diff #89079) | I see. Thanks for pointing this out to me. But does Val have to be a constantInt here. What we know here is that the Cond != Val and we are trying to simplify a icmpinst, we are not getting the actual integer value of this constant. Even though I think the Val is always going to be the constant int in the current state of pass. |
lib/Transforms/Scalar/LoopUnswitch.cpp | ||
---|---|---|
1395 ↗ | (On Diff #89079) | Err, no, you're right... this particular transform works out even if Val isn't a ConstantInt, because you're checking for equality. Sorry, I feel like I'm completely screwing up this review; I'll take another look tomorrow, and hopefully it's clearer then. |
lib/Transforms/Scalar/LoopUnswitch.cpp | ||
---|---|---|
242 ↗ | (On Diff #89079) | The name "Cond" is kind of confusing... it's the condition of some switch somewhere, but that isn't particularly relevant here. Maybe "Invariant" is a better name, since that's the important property? Also, the name of the function isn't great... maybe rename it SimplifyInstructionWithNotEqual? |
1390 ↗ | (On Diff #89079) | This comment is a bit difficult to parse. Maybe just "icmp eq cond, val -> false"? |
1407 ↗ | (On Diff #89079) | Redundant comment. |
There was an iterator invalidation bug here. I committed 296069 (https://reviews.llvm.org/rL296069) to fix the problem. Post-commit reviews welcome.