[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