[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