<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 3, 2017 at 10:03 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</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 bgcolor="#FFFFFF"><div><div class="gmail-h5">
<p><br>
</p>
<div class="gmail-m_7591637374834833862moz-cite-prefix">On 09/03/2017 11:35 PM, Daniel Berlin
wrote:<br>
</div>
<blockquote type="cite">
<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-m_7591637374834833862gmail-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_7591637374834833862gmail-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_7591637374834833862gmail-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_7591637374834833862gmail-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->getArgOpera<wbr>nd(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-m_7591637374834833862gmail-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.</div>
</div>
</div>
</div>
</blockquote>
<br></div></div>
I don't believe we can have this model. We model free, I believe
fairly, as writing to the memory being freed.</div></blockquote><div><br></div><div>I'm going to leave whether that's correct for another day, but if you want to be pedantic, all C11 says is:<br>"The free function causes the space pointed to by ptr to be deallocated, that is, made</div><div>available for further allocation. "</div><div><br></div><div>(I have no urge here to go down the rabbit hole of whether you can free pointers you couldn't load and store due to TBAA or whatever)</div><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"> Thus, we need to
following aliasing rules regarding what it can affect.</div></blockquote><div><br></div><div>Okay.</div><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">Otherwise,
we'd need to model free as potentially modifying anything (because
we'd have no infrastructure to deal with figuring out what it might
affect). <br><span class="gmail-">
<br></span></div></blockquote><div>Correct.</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"><span class="gmail-">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> 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.</div>
</div>
</div>
</div>
</blockquote>
<br></span>
This is what we have, as far as I can tell. It is true that you
can't have an additional call to free(%p1) at the end, but that's
irrelevant, as UB would have already occurred.</div></blockquote><div><br></div><div>So, i instrumented llvm to add runtime asserts about the noaliasing pointers before free (IE it adds an assert that, for each pointer that is noaliased with the pointer passed to free, free is not destroying that pointer), and it fails really quickly.</div><div><br></div><div>Hence, i'm going to go with "i still have trouble believing we are generating currently correct code that accounts for this model".</div><div>Though i admit nothing currently takes advantage of free that i can find.<br></div><div>But at least i feel like i understand what we are trying to model :)</div><div><br></div><br><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></blockquote><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></blockquote><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"><span class="gmail-"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> 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>
</div>
</div>
</blockquote>
<br></span>
I'm not sure what this means.<br></div></blockquote><div><br></div><div>It means unlike malloc, which we've taken from c's memory model and said things about what it does in llvm's, we have decided not to do anything with free</div><div>(IE attempts to rely on saying anything about llvm memory objects based on free is nonsense)</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">
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Thoughts? Other possibilities?<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Referring to this:<span class="gmail-"><br>
<br>
define void @f(i64 %arg, i64 %arg1) {<br>
bb:<br>
%p0 = tail call noalias i8* @malloc(i64 %arg) #3<br>
%p1 = tail call noalias i8* @malloc(i64 %arg) #3<br>
%offset = tail call i64 @subtract(i8* %p1, i8* %p0)<br>
%gep = getelementptr i8, i8* %p0, i64 %offset ;; not inbounds<br>
ret void<br>
}<br>
<br>
declare noalias i8* @malloc(i64)<br>
declare i64 @subtract(i8*, i8*)<br>
<br></span>
In our model, as I understand it, free of %gep: As %gep is based on
%p0, and free must be called with a pointer to the beginning of the
allocation, %offset must be 0. If offset is not 0, the behavior is
undefined.</div></blockquote><div><br></div><div><br></div><div>Then, as i said, i think we've got a lot of cases we aren't generating correct code (though again, nothing is trying to take a lot of advantage of free).</div><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"><span class="gmail-">
</span></div>
</blockquote></div><br></div></div>