When performing runtime unrolling with multiple exits, one of the earlier (non-latch) exits may exit the loop on the first iteration, such that we never branch on the latch exit condition. As such, we need to freeze the condition of the new branch that is introduced before the loop, as it now executed unconditionally.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/Utils/LoopUnrollRuntime.cpp | ||
---|---|---|
755 | Its not clear to me that you need this. The condition being branched on should always be derived from the SCEV computed trip count. After D124910, shouldn't we be assured that is non-poisonous? Or at least, only poisonous if the first input is poison? Your code here is completely reasonable, except that I don't quite understand the case in which is matters. :) |
llvm/lib/Transforms/Utils/LoopUnrollRuntime.cpp | ||
---|---|---|
755 | Runtime loop unrolling doesn't use the backedge taken count (which is what D124910 is about), it works only on the latch exit count. So if you have two exits at n and m (with m being the latch exit), runtime unroll will unroll using m, not umin(n, m). That's why we need to handle this explicitly, it wouldn't be going through the umin_seq code. |
LGTM
llvm/lib/Transforms/Utils/LoopUnrollRuntime.cpp | ||
---|---|---|
755 | You are correct. Odd, I thought we'd changed that previously, but it looks like we haven't. |
Its not clear to me that you need this. The condition being branched on should always be derived from the SCEV computed trip count. After D124910, shouldn't we be assured that is non-poisonous? Or at least, only poisonous if the first input is poison?
Your code here is completely reasonable, except that I don't quite understand the case in which is matters. :)