[PATCH] D67408: [IndVars] An implementation of loop predication without a need for speculation
Evgeniy via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Sep 12 01:48:34 PDT 2019
ebrevnov added a comment.
> I haven't seen anything in the literature which quite matches this. Given that, I'm not entirely sure that keeping the name "loop predication" is helpful. Anyone have suggestions for a better name? This is analogous to partial redundancy elimination - since we remove the condition flowing around the backedge - and has some parallels to our existing transforms which try to make conditions invariant in loops.
Maybe this is because I don't have context on previous work related to LoopPredication but it sounds not quite what the transformation is doing. At least it doesn't generate any explicit predicate for the loop. I don't have anything better to suggest at this time though.
================
Comment at: lib/Transforms/Scalar/IndVarSimplify.cpp:2750
+ // form. If we have a read-only loop, and we can tell that we must exit down
+ // a path which does not need any of the values computed within the loop, we
+ // can rewrite the loop to exit on the first iteration. Note that this
----------------
I can't find a place where this prerequisite is actually checked. Am I just missing it?
================
Comment at: lib/Transforms/Scalar/IndVarSimplify.cpp:2758
+ if (!LoopPredication)
+ return Changed;
+
----------------
Returning at this point means no other code (other than loop predication) can be added bellow this point in future. I think we better structure it in a more independent way. Taking into account this function becomes pretty large I would suggest factoring out new code to a separate function?
================
Comment at: lib/Transforms/Scalar/IndVarSimplify.cpp:2769
+
+ auto Filter = [&](BasicBlock *ExitingBB) {
+ // If our exitting block exits multiple loops, we can only rewrite the
----------------
Looks like many steps in this filter are common with the existing code above. I think it make sense to unify these two pieces. Ideally ExitingBB better be const to prevent unintended influence but not sure this is doable with out a copy.
================
Comment at: lib/Transforms/Scalar/IndVarSimplify.cpp:2827
+ // TODO:isGuaranteedToTransfer
+ if (I.mayHaveSideEffects() || I.mayThrow())
+ return Changed;
----------------
No need to call mayThrow explicitly since mayHaveSideEffects covers this.
================
Comment at: lib/Transforms/Scalar/IndVarSimplify.cpp:2835
+ // it for dedicated passes.
+ // 2) We insert the comparison at the branch. Hoisting introduces additional
+ // legality constraints and we leave that to dedicated logic. We want to
----------------
The first sentence sounds a little odd to me. Would you mind rephrasing it.
================
Comment at: lib/Transforms/Scalar/IndVarSimplify.cpp:2837
+ // legality constraints and we leave that to dedicated logic. We want to
+ // predicate even if we can't insert a loop invariant expression as
+ // peeling or unrolling will likely reduce the cost of the otherwise loop
----------------
Could you clarify this sentence for me. Did not catch.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D67408/new/
https://reviews.llvm.org/D67408
More information about the llvm-commits
mailing list