[LLVMdev] Deriving undefined behavior from nsw/inbounds/poison for scalar evolution

[Bjarke Roune]

Hi Sanjoy, thanks for your thoughts on this.

On Sat, Jun 27, 2015 at 12:16 AM, Sanjoy Das <sanjoy at playingwithpointers.com
> wrote:
>
> First of all, going by the "poison causes UB only when observed", SCEV
> does not do the right thing currently: [...]
>
> That seems like a bug? There's also bug 23527 for GEP. Sounds like there
might be more such bugs.

One way to get what you want and also fix this existing bug(?) is to
> make the no wrap flags part of a SCEV expression's identity (i.e. make
> {A,+,B}<nuw> a different expression from {A,+,B}).  If you start with
> the precondition that every <nuw> [0] came from a <nuw> [1] present in
> the IR, then you don't really have to worry about control dependence
> -- you can always optimize under the assumption that the SCEV
> expression does not unsign-overflow; if such an optimization changes
> program behavior then that program has UB since it was data dependent
> on poison [2].


To make sure that I understand correctly, are you suggesting making the nuw
(and similar) flags part of the key when looking up an SCEV in the
UniqueSCEVs member variable on ScalarEvolution? That way, an instruction
with nuw and one without will not map to the same SCEV unless the nuw can
be inferred in some other way. Sounds good to me, I'm happy to go with
either one of that or inferring UB from poison.

Adding the flags to the key/identity does break the idea that
mathematically equivalent expressions should cancel if subtracted. Andrew
Trick wrote something about that previously:


http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141215/249390.html

Andrew: I wonder what your view is on this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150630/11ad37f8/attachment.html>