Currently, UnrollLoop() is passed an AllowRuntime flag and decides itself whether runtime unrolling should be used or not. This patch pushes the decision into the caller and allows us to eliminate the ULO.TripCount and ULO.TripMultiple parameters.
Details
Diff Detail
Event Timeline
llvm/lib/Transforms/Utils/LoopUnroll.cpp | ||
---|---|---|
391 | I'm not particularly familiar with convergent operations, but looking back at D17526 the concern here seems to have been specifically about the prologue introduced by runtime unrolling, not anything else. | |
llvm/lib/Transforms/Utils/LoopUnrollAndJam.cpp | ||
251 | This change deserves a comment: If TripMultiple is 1 and Count is 1 and UnrollRemainder was set, this tried to unroll the remainder loop with a Count of 0, which is not legal. It wasn't caught previously due to the check // Don't enter the unroll code if there is nothing to do. if (ULO.TripCount == 0 && ULO.Count < 2) { which happened before the assert(Count > 0) assertion. I've removed that check and the assertion is triggered now. The change here adjust things to not try to create a remainder loop for an unroll count of 1, as this doesn't make sense in the first place. |
I'm not particularly familiar with convergent operations, but looking back at D17526 the concern here seems to have been specifically about the prologue introduced by runtime unrolling, not anything else.