[llvm] [DA] Check monotonicity for subscripts (PR #154527)

Ryotaro Kasuga via llvm-commits llvm-commits at lists.llvm.org
Fri Aug 22 09:53:44 PDT 2025


kasuga-fj wrote:

Thanks for the feedback!

> This seems to only support AddRecExpr directly, I was thinking about something recursive that may contain an AddRecExpr, such as an SignExtend/ZeroExtend/Division/... of an SCEVAddRecExpr.

Changed the implementation to use the `SCEVVisitor` class, and now handled more cases.

> SCEVTruncate maybe illustrates that the "monotonic" property not only applies to SCEVAddRecExpr.
> 
> ```
> trunc 0x101 to i8 -> 0x01
> trunc 0x203 to i8 -> 0x03
> trunc 0x302 to i8 -> 0x02
> ```
> 
> Say the values 0x101, 0x203, 0x302 are the iteration values a loop[1](#user-content-fn-1-5b86d8afd276e067e3ce90b31fb50789). The maximum of the trunc expression is `0x03`, which is neither the value of the initial AddRecExpr loop iteration, nor its last. That is, the range of indices in an array subscipt expression `A[(char)i]` is not 0x01 to 0x02.

It actually seems monotonic, but I'm not sure the correct way to handle such cases... Let me think about it for a moment.
 
> I would have thougth of getting the min/max of an expression as a separate operation. Ideally, the simplication of SMin/SMax expression could be done by ScalarEvolution itself through canonicalization/folding.

Splitted it in another class `SCEVMinMaxCalculator`. Do you mean that this should be defined as an API of `ScalarEvolution`?

So, I believe the overall approach is not too far off, so for now I'll check the tests and clean up the code.

I’d like to ask one question: I feel like these processes (monotonic checks, validation for delinearization, etc.) should be tested separately from other parts of DA. What do you think? Would that be a bit excessive?

https://github.com/llvm/llvm-project/pull/154527


More information about the llvm-commits mailing list