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

[George Burgess IV via llvm-commits]

george.burgess.iv added inline comments.

================
Comment at: lib/Analysis/CFLAliasAnalysis.cpp:1014
@@ +1013,3 @@
+        if (MaybeCurAttr && Direction == Level::Below)
+          Builder.noteAttributes(OtherValue, *MaybeCurAttr);
+
----------------
grievejia wrote:
> george.burgess.iv wrote:
> > ISTM we would end up with different attributes for the StratifiedSets in cases like:
> > 
> > ```
> > void foo(int **a) {
> >   int **aalias = a;
> >   int *b = *a;
> > }
> > ```
> > 
> > and
> > 
> > ```
> > void foo(int **a) {
> >   int **aalias = a;
> >   int *b = *aalias;
> > }
> > ```
> > 
> > ...Since, when analyzing `*a`, MaybeCurAttr is marked as External (and Arg #0), whereas when looking at `*aalias`, we won't mark any attributes. After set finalization/etc, the former code sample will end with two sets, each with External and Arg #0 attrs, but the latter will produce two sets with only the External attr set.
> > 
> > Is this intentional?
> But a and aalias will be merged together into one node later, right? Whatever attribute that a gets will be transferred to aalias.
> But a and aalias will be merged together into one node later, right? Whatever attribute that a gets will be transferred to aalias

Sure, but I'm talking about `b`'s set. :)

In the former case, `b`'s set will end up with a different set of attributes than the latter case, since `valueToAttr(aalias)` won't return argument attributes, whereas `valueToAttr(a)` does.

So, we would have differing attributes on `b`'s set in both cases, no?


http://reviews.llvm.org/D21110