<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 09/04/2017 01:40 AM, Daniel Berlin
wrote:<br>
</div>
<blockquote
cite="mid:CAF4BwTWMoMQfVA-RjLFTQAL6M8fdPCxMr-RFVo9dCb-ppom6Mg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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 moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
<br>
Are these live pointers? (i.e., could this be caused because malloc
is recycling memory blocks?)<br>
<br>
<blockquote
cite="mid:CAF4BwTWMoMQfVA-RjLFTQAL6M8fdPCxMr-RFVo9dCb-ppom6Mg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
<br>
Sounds good. ;)<br>
<br>
We should be a bit careful, however. Or, at least I should ;) -- I'd
like to get back to doing heap-to-stack conversion at some point.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CAF4BwTWMoMQfVA-RjLFTQAL6M8fdPCxMr-RFVo9dCb-ppom6Mg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>