[llvm-dev] Improving SCEV's behavior around IR level no-wrap flags

[Andrew Trick via llvm-dev]

> On Sep 23, 2016, at 7:50 AM, Christof Douma <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.

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?

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160923/fa7ded68/attachment.html>