[llvm-dev] Improving SCEV's behavior around IR level no-wrap flags
Sanjoy Das via llvm-dev
llvm-dev at lists.llvm.org
Sat Sep 24 00:07:55 PDT 2016
Andrew Trick wrote:
> Maybe. Or the answer might be to insert a check outside the
> loop. This is what I’m really getting at: do you see the Instruction
> nsw flags as useful apart from UB?
Not within SCEV. Marking provably non-overflowing instructions as
nsw/nuw has non-trivial benefit for optimizations *outside* SCEV, but
that's orthogonal to this discussion.
> Are you flagging them now after
> proving nsw based on some @guard intrinsics or other dominating
Just be clear: in this thread I'm speaking in the "SCEV maintainer"
capacity, not in the "Java frontend engineer" capacity. :)
IR from our Java frontend does not exhibit this kind of problem since
it does not have any overflow-related UB that SCEV needs to "exploit".
When SCEV is able to _prove_ a certain add recurrence or arithmetic
won't overflow, and in that case mutating the SCEV expression to mark
it as no-wrap is the correct and sound thing to do anyway.
More information about the llvm-dev