<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 11, 2017 at 3:31 PM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On April 11, 2017 at 3:28:04 PM, Kostya Serebryany (<a href="mailto:kcc@google.com">kcc@google.com</a>) wrote:<br>
> On Tue, Apr 11, 2017 at 3:14 PM, Sanjoy Das<br>
</span><div><div class="h5">> wrote:<br>
><br>
> > Hi Kostya,<br>
> ><br>
> > On April 11, 2017 at 2:39:44 PM, Kostya Serebryany (<a href="mailto:kcc@google.com">kcc@google.com</a>) wrote:<br>
> > > > ptr0 = malloc();<br>
> > > > free(ptr0);<br>
> > > > ptr1 = malloc();<br>
> > > ><br>
> > > > ptr0 and ptr1 will be NoAlias despite overlapping (there is actually a<br>
> > > > real soundness issue here in LLVM's semantics, but I don't want to<br>
> > > > digress). You can also recreate the pattern with realloc.<br>
> > > ><br>
> > ><br>
> > > In both of your examples there is no place in the program where both P0<br>
> > and<br>
> > > P1 are live simultaneously,<br>
> > > i.e. no analysis path is expected to query MayAlias(AccessToP0,<br>
> > > AccessToP1). No?<br>
> ><br>
> > I may be misunderstanding what you meant, but I don't see why not.<br>
> ><br>
> > Say you had (all values are SSA values):<br>
> ><br>
> > %p0 = malloc()<br>
> > store i32 0, i32* %p0 // S0<br>
> > free(%p0)<br>
> > %p1 = malloc()<br>
> > store i32 1, i32* %p1 // S1<br>
> ><br>
> > and some pass wanted to sink S0 to after S1. So it starts checking<br>
> > "from the bottom", as<br>
> ><br>
> > Alias(S0, S1) = NoAlias<br>
> > Alias(S0, malloc()) = NoAlias<br>
> > Alias(S0, free(%p0)) = MayAlias<br>
> ><br>
> > etc. The last MayAlias will prevent it from doing the sink, but I<br>
> > don't see why it can't ask the Alias(S0, S1) question.<br>
> ><br>
><br>
> Yea, that's a bit trickier.<br>
> But we can at least add checks for pairs of pointer accesses that the<br>
> analysis claims to be ok to reorder.<br>
<br>
</div></div>But that the problem right -- AA told you that S0 and S1 *are* okay to<br>
reorder.  In fact, if your original program would have been:<br>
<br>
p0 = malloc()<br>
free(p0)<br>
p1 = malloc()<br>
*p0 = 20  // S0<br>
*p1 = 20  // S1<br>
<br>
then S0 and S1 would have been okay to reorder (since the original<br>
program has UB).  But you cannot assert !overlap(p0, p1) in the well<br>
defined program I mentioned earlier.<br></blockquote><div><br></div><div>Yea.. tricky... </div><div>Well, if we combine this kind of checking with asan your particular problem is gone (because asan has quarantine for free-d memory and it won't be reused immediately)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-- Sanjoy<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
><br>
><br>
> ><br>
> > > > The same problem exists with constant addresses. LLVM states that<br>
> > > > constant locations are noalias with themselves, and you again have the<br>
> > > > "noalias does not imply pointer inequality" problem.<br>
> > ><br>
> > > That won't even have to be special cased, because if we emit a check<br>
> > > ConstPtr != ConstPtr,<br>
> > > such a check will be trivially optimized away.<br>
> ><br>
> > But won't it be constant folded to trigger the sanitizer crash /<br>
> > warning? That is, since LLVM will state the ConstPtr NoAlias<br>
> > ConstPtr, you'll emit the check:<br>
> ><br>
> > if (overlap(ConstPtr, Sz, ConstPtr, Sz))<br>
> > abort();<br>
> ><br>
> > which will get constant folded to<br>
> ><br>
> > if (true) abort();<br>
> ><br>
><br>
> ah, yes, you are right, then this will have to be special-cased.<br>
><br>
><br>
> ><br>
> > If you meant that the implementation of overlap will differ based on<br>
> > whether the pointers are constant pointers or not, I'm not sure if<br>
> > that will work, since the fact that the values whose aliasness (I<br>
> > think I invented a new word :P ) you're checking could have been<br>
> > arbitrarily obscured (AA could have looked through PHIs and selects<br>
> > etc.) which will prevent you from rediscovering that the values were<br>
> > constant pointers in some cases.<br>
> ><br>
> > -- Sanjoy<br>
> ><br>
><br>
</div></div></blockquote></div><br></div></div>