[PATCH] D110972: [DA] Handle mismatching loop levels by updating the numbering scheme
Congzhe Cao via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Apr 21 00:25:04 PDT 2022
congzhe added a comment.
In D110972#3463438 <https://reviews.llvm.org/D110972#3463438>, @Meinersbur wrote:
> I think the correct fix is to handle `AddRecExpr` from a loop outside `LoopNest` like other non-AddRec expressions. At the moment this means "non-linear" (like D110973 <https://reviews.llvm.org/D110973>) unless it is completely loop-invariant. This is a limitation of the current `checkSubscript` that does not look into other kinds of SCEV expressions. In `@test1`/`@test2` this is all we can do because `%c.1.lcssa` (which has the value of `%add27` when the loop exists) has an undefined value because with the backedge branch on `undef`, `%c.1.lcssa` is undefined which usually is not considered "linear".
>
> `DependenceInfo::depends` should actually call `getSCEVAtScope` instead of just `getScev` (like `tryDelinearize` already does), because if ScalarEvolution can understand the backedge taken count, the SCEVAddRecExpr will be simplified to that result.
Are you essentially suggesting that we follow the approach in D110973 <https://reviews.llvm.org/D110973>, and improve it by using `getSCEVAtScope()` such that we may be able to infer some of those `AddRec` (like in the lcssa case) to be loop invariant with respect to `LoopNest`? If that is the case then we may want to add another test that is a mirror of `@test1` but not using `undef` as the loop exit condition?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D110972/new/
https://reviews.llvm.org/D110972
More information about the llvm-commits
mailing list