<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 8, 2016 at 1:40 PM, Jia Chen via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">grievejia added a comment.<br>
<br>
In <a href="http://reviews.llvm.org/D21110#452666" rel="noreferrer" target="_blank">http://reviews.llvm.org/D21110#452666</a>, @george.burgess.iv wrote:<br>
<br>
> Tests, please. :)<br>
<br>
<br>
Sorry I should've mentioned it in the description. The test I uploaded with the last patch (attr-escaped.ll) should serve the purpose. There's a CHECK on an AttrEscaped value and an AttrExternal value in that test.<br>
<span class=""><br>
> Also, can you please go over how this doesn't make arg/global attributes basically redundant?<br>
<br>
<br>
</span>Arg/Global attributes are practically identical to AttrUnknown at this moment, except that we know a little bit more on their origins. Arg/Global/Unknown all represent "values that we don't know where they come from". They may alias each other in arbitrary way. Basically, everything we load through AttrExternal values should be put in this class.<br>
<br>
AttrExternal, on the other hand, is only used to tag global values/arguments themselves. say we have this function:<br>
<br>
  define @foo(i32** %x) {<br>
    %y = load i32*, i32** %x<br>
    %z = alloca i32<br>
    ...<br>
  }<br>
<br>
Then %x will be marked AttrExternal, and %y will be marked AttrArg0 (which if functionally equivalent to AttrUnknown). The motivation for separating AttrArg and AttrExternal is that if we don't, CFLAA will say that if %z escapes then %z may alias %x, which could be made less conservative.<br>
<span class=""><br>
> Any set tagged with External attributes will have all sets below it tagged with External.<br>
<br>
<br>
</span>Yes. But AttrGlobal/AttrArgXXX takes precedence over it. So I don't see AttrExternal breaks soundness here.<br>
<span class=""><br>
> So, it looks like this change would make it more difficult to handle interprocedural queries where we know the source of arguments.<br>
<br>
<br>
</span>We didn't lose the information for the memory objects that get pointed to by globals/arguments. We only lose the information on the globals/arguments themselves. It is also possible to preserve the information at the value level by further expanding AttrExternal into AttrExternalGlobal, AttrExternalArg0.<br>
<br>
As I put more thoughts on it I also start to grow suspicious about the idea that separating AttrGlobals/Args from AttrUnknown is somewhat useful. </blockquote><div><br></div><div>FWIW, it is very useful in most cases.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The intention, as you mentioned in our earlier discussion, is that if we can prove from the caller that certain globals/args don't alias then we may be able to improve upon precision. However, since we are doing a bottom-up style summary-based analysis here, the callees are always going to be analyzed before the callers (assume the absense of callgraph cycles). At the time when the callee is analyzed, we can't use any information from the caller because they may not be available yet. </blockquote><div><br></div><div>I'm not sure you need to prove this from the *caller*.</div><div>You only need to locally propagate whether something has happened in the callee.</div><div><br></div><div>Given</div><div><br></div><div>int foo()<br>{<br>bar();</div><div>}</div><div><br></div><div>int bar()</div><div>{<br>  baz();</div><div>}</div><div><br></div><div>...</div><div><br></div><div>The order of processing will be baz, then bar, then foo.</div><div><br></div><div>If you locally analyze whether the function, and any of its callees (which you will have complete info for at that point) alias any globals, you will know the answer for each function whether that function does something with globals or externals.</div><div><br></div><div>Now, the traditional solution is bottom-up followed by top-down propagation, but ...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">At the time when the caller is analyzed, we have the callee's info but it is not clear to me how AttrGlobal/AttrArgs can be utilized there. I was thinking maybe we should get rid of them at some point. But I'm also not 100% confident that they are completely useless...<br></blockquote><div><br></div><div><br></div></div></div></div>