<div dir="ltr">On Mon, Sep 8, 2014 at 8:36 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Sep 8, 2014 at 4:22 PM, Dan Gohman <span dir="ltr"><<a href="mailto:dan433584@gmail.com" target="_blank">dan433584@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>It looks a little silly to say this in the case of the integer constant 5, and there are some semantic gray areas around extra-VM allocation, but the same thing happens if the add were adding a dynamic integer value, and then it's difficult to find a way to separate that case from the constant 5 case.</div></div></blockquote><div><br></div></span><div>Could we say that constant integers have no objects associated with them? If so, we need a way to bless constant integers that *do* refer to real objects, such as ASan's shadow memory base.</div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Then you should be able to take something like add a phi of constant ints to an inttoptr and transform that to a GEP, without explicitly calling out constant integers.</div><span class=""><div></div></span></div></div></div></blockquote><div><br>It's not pretty to have situations where dynamic 
values permit more optimization than constants. If there's an expression
 which can be folded to a constant int, should the constant folder avoid
 doing so, because it might pessimize subsequent alias analysis?<br><br></div><div>Also, if you follow it to its semantic conclusion, even this isn't enough, because 5 may be associated with *any* fixed address, in the same way that p - 1000000 (which is valid to compute with a gep as long as you don't use inbounds) is still associated with p's set, even though it's pointing somewhere quite different. Associated-with is necessary but not sufficient for a valid dereference.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>In any case, the general advice is that people should prefer to use getelementptr to begin with. LLVM's own optimizers were converted to use getelementptr instead of ptrtoint+add+inttoptr even when they have to do raw byte arithmetic.</div></div></blockquote><div><br></div></span><div>I'm guessing the IR comes from C++ code that subtracts pointers, so it'd be good if we could figure this out.</div></div></div></div>
</blockquote></div><br></div><div class="gmail_extra">A more complete testcase would be helpful here. This situation doesn't arise from simple pointer differences, so we should look at what other things it's interacting with to get here.<br></div></div>