<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 09/03/2017 11:35 PM, Daniel Berlin
wrote:<br>
</div>
<blockquote
cite="mid:CAF4BwTVii43AF28P9vkmUgJYevsuVRUf0O2-DqXMGArzTt=J2Q@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 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-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_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.</div>
</div>
</div>
</div>
</blockquote>
<br>
I don't believe we can have this model. We model free, I believe
fairly, as writing to the memory being freed. Thus, we need to
following aliasing rules regarding what it can affect. 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>
<br>
<blockquote
cite="mid:CAF4BwTVii43AF28P9vkmUgJYevsuVRUf0O2-DqXMGArzTt=J2Q@mail.gmail.com"
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>
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.<br>
<br>
<blockquote
cite="mid:CAF4BwTVii43AF28P9vkmUgJYevsuVRUf0O2-DqXMGArzTt=J2Q@mail.gmail.com"
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>
I'm not sure what this means.<br>
<br>
<blockquote
cite="mid:CAF4BwTVii43AF28P9vkmUgJYevsuVRUf0O2-DqXMGArzTt=J2Q@mail.gmail.com"
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:<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>
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.<br>
<br>
-Hal<br>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>