<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 3, 2017 at 7:17 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</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 class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div><div class="gmail-m_5469766377204925682h5"><br></div></div>
    Sanjoy's description of the current behavior is accurate. </div></blockquote><div><br></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 bgcolor="#FFFFFF">I see two
    ways of looking at this:<br>
    <br>
     1. This is a bug.<br>
     2. To allow this kind of inter-object addressing you need to use
    inttoptr/ptrtoint.<br>
    <br></div></blockquote><div><br></div></span><div>I'm fine with #2, i just feel like our rules are a little hodgepodge:)</div><span class="gmail-"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    I don't believe that it is possible for the current behavior to
    manifest as a problem for C/C++ (and this is likely the same for
    most higher-level languages).</div></blockquote><div><br></div></span><div>I don't believe it is either - we've already stated we assume aliasing does not imply pointer equality and non-aliasing does not imply pointer inequality.</div><div>If we did, this behaviour could.</div></div></div></div></blockquote><div><br></div><div>Which means the weirdest discontinuity that occurs to me off the top of my head is that we are treating malloc's like lifetime beginning operations in a bunch of cases (GVN does this) , but if you call free on the pointer from the gep in sanjoy's example, there is no way to know it could have ended the lifetime of both p0 and p1 without a separate analysis.</div><div><br></div><div>It means things like this in memorydependenceanalysis:<br><div><br></div><div>  if (const CallInst *CI = isFreeCall(Inst, &TLI)) {</div><div>    // calls to free() deallocate the entire structure</div><div>    Loc = MemoryLocation(CI->getArgOperand(0));</div><div>    return MRI_Mod;</div><div>  }</div></div><div>will say this free does not touch p1, even though it could have destroyed it and ended the lifetime.</div><div><br></div><div>Do we have anything that takes advantage and does something silly? I don't think we have anything that advanced ATM.</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div>