[PATCH] D21110: [CFLAA] Add yet another StratifiedAttr

[Jia Chen via llvm-commits]

grievejia added a comment.

In http://reviews.llvm.org/D21110#452666, @george.burgess.iv wrote:

> Tests, please. :)


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.

> Also, can you please go over how this doesn't make arg/global attributes basically redundant?


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.

AttrExternal, on the other hand, is only used to tag global values/arguments themselves. say we have this function:

  define @foo(i32** %x) {
    %y = load i32*, i32** %x
    %z = alloca i32
    ...
  }

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.

> Any set tagged with External attributes will have all sets below it tagged with External.


Yes. But AttrGlobal/AttrArgXXX takes precedence over it. So I don't see AttrExternal breaks soundness here.

> So, it looks like this change would make it more difficult to handle interprocedural queries where we know the source of arguments.


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.

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. 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. 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...


http://reviews.llvm.org/D21110