The findInnerReductionPhi function is looking for reduction variables,
which cannot be constants; also, walking users of some Constants (particularly ConstantData)
doesn't make semantic sense in a function pass since its users can be spread among different
functions or modules that happen to be in the same LLVMContext
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
@fhahn, can you help with the review here? This is one of only a few instances of walking the use-list of ConstantData. The broader context is an old RFC that @willir is working with me on:
https://lists.llvm.org/pipermail/llvm-dev/2016-September/105157.html
(I know the motivation and context, but I'm not the right person to review functional changes to this pass.)
llvm/lib/Transforms/Scalar/LoopInterchange.cpp | ||
---|---|---|
663–675 | It looks like sometimes findInnerReductionPhi is running on ConstantData, which can come from another function (or module), and will eventually lose its use-lists (no one should walk the use-list of i1 0; usually anything they learn from that will be wrong).
|
llvm/lib/Transforms/Scalar/LoopInterchange.cpp | ||
---|---|---|
663–675 |
I think findInnerReductionPhi should never return anything other than nullptr for constants; it is looking for a reduction results, which should always be an instruction. So returning nullptr on isa<Constant> seems the best way forward. It would also be good to add a test with LCSSA phis with constant incoming values, e.g something like the below to llvm/test/Transforms/LoopInterchange/reductions-across-inner-and-outer-loop.ll define i64 @test1([100 x [100 x i64]]* %Arr) { entry: br label %for1.header for1.header: ; preds = %for1.inc, %entry %indvars.iv23 = phi i64 [ 0, %entry ], [ %indvars.iv.next24, %for1.inc ] %sum.outer = phi i64 [ 0, %entry ], [ %const.lcssa, %for1.inc ] br label %for2 for2: ; preds = %for2, %for1.header %indvars.iv = phi i64 [ 0, %for1.header ], [ %indvars.iv.next.3, %for2 ] %sum.inner = phi i64 [ %sum.outer, %for1.header ], [ %sum.inc, %for2 ] %arrayidx = getelementptr inbounds [100 x [100 x i64]], [100 x [100 x i64]]* %Arr, i64 0, i64 %indvars.iv, i64 %indvars.iv23 %lv = load i64, i64* %arrayidx, align 4 %sum.inc = add i64 %sum.inner, %lv %indvars.iv.next.3 = add nuw nsw i64 %indvars.iv, 1 %exit1 = icmp eq i64 %indvars.iv.next.3, 100 br i1 %exit1, label %for1.inc, label %for2 for1.inc: ; preds = %for2 %const.lcssa = phi i64 [ 1, %for2 ] %indvars.iv.next24 = add nuw nsw i64 %indvars.iv23, 1 %exit2 = icmp eq i64 %indvars.iv.next24, 100 br i1 %exit2, label %for1.loopexit, label %for1.header for1.loopexit: ; preds = %for1.inc %const.lcssa2 = phi i64 [ %const.lcssa, %for1.inc ] ret i64 %const.lcssa2 } |
Make findInnerReductionPhi return nullptr on isa<Constant> as suggested
by @fhahn.
Add a test for that case.
llvm/lib/Transforms/Scalar/LoopInterchange.cpp | ||
---|---|---|
664 | Could you add a comment with the reasoning for the early exit here? |
LGTM, thanks!
Do not traverse ConstantData use-list in LookInterchange
There's a typo in the title: LookInterchange -> LoopInterchange. Please adjust before committing.
llvm/lib/Transforms/Scalar/LoopInterchange.cpp | ||
---|---|---|
666 | thanks for the comment. The bit about walking users of constants seems a bit verbose and I think it would be better to have this rule documented in a single place, rather than adding it at all the places that are going to be updated. I'd remove it here. |
LGTM too; agreed the comment could be trimmed down too, but I think it's important to have something about that in the commit message.
@willir, I can commit this for you once you update the patch.
Thanks for the review. I hope the current comment looks better.
Here is my git info:
- GIT_AUTHOR_NAME="Anton Rapetov"
- GIT_AUTHOR_EMAIL="willir29@gmail.com"
Pushed in bfec9148a042c8fd6093ae0d54c784211a295c6c with some minor tweaks to the comments and commit message.
Could you add a comment with the reasoning for the early exit here?