llvm dev - Sep 2016 - Improving SCEV's behavior around IR level no-wrap flags

Hi Andy,

Andrew Trick wrote:
 >> On Sep 23, 2016, at 7:50 AM, Christof Douma <Christof.Douma at
arm.com <mailto:Christof.Douma at arm.com>> wrote:
 >>
 >> I can’t help to ask. Why not define a wrapping nsw instruction as UB,
instead of “delayed UB” aka poison? I believe we
 >> have the notion of poison solely to ease the movement of instructions.
In my example above line 6 can be moved to line
 >> 2 due to poison. If the wrapping was UB such a move is still possible
but would require dropping the nsw flag, nothing
 >> more. If this information loss is considered a problem, the use of
llvm.assume can counter that.
 >>
 >> Has somebody ever looked at not having poison at all? What are the
downsides of that?
 >
 > That’s basically incompatible with transformation of the IR. I’m sure
that’s been explained by DanG in the past, but I
 > don’t have a link. e.g. the optimizer doesn’t think that an ‘add’ has side
effects and wants to freely hoist and combine
 > these operations. If the operation has an ‘nsw’ flag that would change the
UB semantics.

+1.

 > I have to say, my heart is not really into optimizing for UB. Is this
relevant to any scenario other than legacy
 > C-without-overflow/bounds checks?

I don't think we'll be able to give up on C and C++ inspired
optimizations anytime soon.  Given what I've seen on llvm-dev and
bugzilla, it is pretty clear to me that we have to do _something_ to
address the missing pieces here.

-- Sanjoy

> On Sep 23, 2016, at 10:32 PM, Sanjoy Das <sanjoy at
playingwithpointers.com> wrote:
> 
> Hi Andy,
> 
> Andrew Trick wrote:
> >> On Sep 23, 2016, at 7:50 AM, Christof Douma <Christof.Douma at
arm.com <mailto:Christof.Douma at arm.com>> wrote:
> >>
> >> I can’t help to ask. Why not define a wrapping nsw instruction as
UB, instead of “delayed UB” aka poison? I believe we
> >> have the notion of poison solely to ease the movement of
instructions. In my example above line 6 can be moved to line
> >> 2 due to poison. If the wrapping was UB such a move is still
possible but would require dropping the nsw flag, nothing
> >> more. If this information loss is considered a problem, the use of
llvm.assume can counter that.
> >>
> >> Has somebody ever looked at not having poison at all? What are the
downsides of that?
> >
> > That’s basically incompatible with transformation of the IR. I’m sure
that’s been explained by DanG in the past, but I
> > don’t have a link. e.g. the optimizer doesn’t think that an ‘add’ has
side effects and wants to freely hoist and combine
> > these operations. If the operation has an ‘nsw’ flag that would change
the UB semantics.
> 
> +1.
> 
> > I have to say, my heart is not really into optimizing for UB. Is this
relevant to any scenario other than legacy
> > C-without-overflow/bounds checks?
> 
> I don't think we'll be able to give up on C and C++ inspired
> optimizations anytime soon.  Given what I've seen on llvm-dev and
> bugzilla, it is pretty clear to me that we have to do _something_ to
> address the missing pieces here.
> 
> -- Sanjoy
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? Are you flagging them now after proving nsw based on some @guard intrinsics
or other dominating checks?

-Andy

Hi Andy,

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
 > checks?

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.

-- Sanjoy