<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi Sanjoy, thanks for your thoughts on this.</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Sat, Jun 27, 2015 at 12:16 AM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
First of all, going by the "poison causes UB only when observed", SCEV<br>
does not do the right thing currently: [...]<br>
<br></blockquote><div>That seems like a bug? There's also <span style="font-size:12.8000001907349px">bug 23527 for GEP. Sounds like there might be more such bugs.</span></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
One way to get what you want and also fix this existing bug(?) is to<br>
make the no wrap flags part of a SCEV expression's identity (i.e. make<br>
{A,+,B}<nuw> a different expression from {A,+,B}). If you start with<br>
the precondition that every <nuw> [0] came from a <nuw> [1] present in<br>
the IR, then you don't really have to worry about control dependence<br>
-- you can always optimize under the assumption that the SCEV<br>
expression does not unsign-overflow; if such an optimization changes<br>
program behavior then that program has UB since it was data dependent<br>
on poison [2].</blockquote><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div> <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141215/249390.html">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141215/249390.html</a><br></div><div><br></div><div>Andrew: I wonder what your view is on this?<br></div><div> </div></div></div></div>