[llvm-dev] RFC: Resolving TBAA issues

[Daniel Berlin via llvm-dev]

One more.
Your original example was:

> Consider these two accesses:
>
>     struct A { int i; };
>     struct B { struct A a; } *b;
>
>     struct X { int i; } *x;
>
>     b->a
>     x->i
>


Do you believe the answer changes if you had struct A *x instead of struct
X *x?
If so, why?

On Sat, Aug 19, 2017 at 10:58 AM, Daniel Berlin <dberlin at dberlin.org> wrote:

>
>
> On Sat, Aug 19, 2017 at 10:48 AM, Ivan A. Kosarev <
> ikosarev at accesssoftek.com> wrote:
>
>> Daniel,
>>
>> > This is an aggregate type that includes a type compatible
>> > with the effective type of the object.  In particular,
>> > x->i is an lvalue expression of type "int"
>> > b->a is an lvalue expression of type "struct A"
>> > "struct A" is an aggregate type that includes "int" among
>> > its members.
>> > Therefore, the b->a object may access x->i by TBAA
>>
>> My understanding is in x->i there are two accesses by lvalue, of which
>> the first one is (*x) and that lvalue is of type that is not compatible
>> with [any part of] struct A.
>>
>
> Assume we split it as you suggest, into foo = *x, foo.i and bar = *b, b.a
>
> *x contains a struct containing an int.
>
> *b contains a struct containing a struct containing an int
>
> " an aggregate or union type that includes one of the aforementioned types
> among its elements or nonstatic
> data members (including, recursively, an element or non-static data member
> of a subaggregate
> or contained union),"
>
> This seems to fall into the "including, recursively" part.
>
> But, let's assume that is true for a second.
>
> GIven
> struct A *a
> struct X *x
>
> a->i
> x->i
>
> Can these accesses alias?
>
>
> struct B *b
> struct X *x
>
> b->a.i
> x->i
>
> How about these?
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170819/4e1388f8/attachment-0001.html>