<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 3, 2017 at 7:52 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"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-h5">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-m_1578106360784931343gmail-"><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_1578106360784931343gmail-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-m_1578106360784931343gmail-"><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></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-><wbr>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></div></div></blockquote><div><br></div><div>Actually, this is, IMHO, worse than i initially thought.</div><div><br></div><div>So imagine we free %gep from sanjoy's example.</div><div><br></div><div>Right now, the above code (and elsewhere) will say that free does not MOD %p1. Even if the pointer is value equal to %p1</div><div><br class="gmail-Apple-interchange-newline">We already say malloc operates by returning new memory regardless of what pointer value it returns. Here, free is taking a pointer and we are saying it only modifies the memory that pointer can alias.</div><div><br></div><div>I can think of a few possibilities</div><div><br></div><div>1. Free operates by pointer value and not "abstract memory location", in which case, the above code is wrong, as free will modify things that are value equal, even if they do not alias. In this model, except through value numbering or range analysis, you can't really ever tell what free has done, it may mod/ref anything (and we have some bugs to fix).</div><div><br></div><div>Also now malloc returns abstract memory objects, but free doesn't really destroy them</div><div><br></div><div>2. An attempt by free to destroy p1 is considered UB, and sanjoy's code, with a free at the end cannot validly destroy p1. I would have trouble believing we are generating currently correct code in this model from any of our frontends, but willing to be convinced (IE i would believe if i added asserts to free calls that they are not value equal to anything llvm considers the argument to noalias, it would fail)</div><div><br></div><div>3. Free is not mapped into our memory model, but malloc is.</div><div><br></div><div>Thoughts? Other possibilities?<br><br></div></div></div></div>