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

[Daniel Berlin via llvm-commits]

On Wed, Jun 8, 2016 at 1:40 PM, Jia Chen via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

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


FWIW, it is very useful in most cases.


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


I'm not sure you need to prove this from the *caller*.
You only need to locally propagate whether something has happened in the
callee.

Given

int foo()
{
bar();
}

int bar()
{
  baz();
}

...

The order of processing will be baz, then bar, then foo.

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.

Now, the traditional solution is bottom-up followed by top-down
propagation, but ...


> 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...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160608/4b217567/attachment.html>