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>
Daniel,
>> the type of (*x) is not compatible with the type of (*b) or,
>> recursively, type of b->i. Similarly, the type of (*b) is not
>> compatible with (*x) or, recursively, x->i.
...
> I think these are interesting interpretations. I'm not sure
> i'd personally agree with them (and there are definitely
> compilers out there that do not).
I wonder how you know that those compilers interpret it differently. If
the correct answer for a specific case is "no alias", then reloading
of
values does not say anything about how authors interpret the cited clause.
It's only omission of reloading that does matter.
> It gets more weird with unions.
Would you mind if we proceed with concrete examples from this point?
>> 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?
So then it reads:
struct A { int i; } *x;
struct B { struct A a; } *b;
b->a
x->i
These two accesses are allowed overlap as the type of b->a is compatible
with the type of (*x).
I should admit I don't see what makes this case special. Can you
elaborate please?
Thanks,
--
On Sat, Aug 19, 2017 at 1:04 PM, Ivan A. Kosarev via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Daniel, > > >> the type of (*x) is not compatible with the type of (*b) or, > >> recursively, type of b->i. Similarly, the type of (*b) is not > >> compatible with (*x) or, recursively, x->i. > ... > > I think these are interesting interpretations. I'm not sure > > i'd personally agree with them (and there are definitely > > compilers out there that do not). > > I wonder how you know that those compilers interpret it differently.I know how to produce internal pass dump files and debug output from a lot of compilers (XLC, ICC, GCC, etc) So i'm staring at the debug output to see what it says.> Would you mind if we proceed with concrete examples from this point? > > I don't believe we are ever going to agree, so i'm not sure there is apoint.> These two accesses are allowed overlap as the type of b->a is compatible > with the type of (*x).Errr, previously you split the access into one, and said it's about whether each part is compatible. So i assume then you also believe *b is compatible with *x here?> I should admit I don't see what makes this case special. Can you elaborate > please? >Honestly? I don't find your answers that consistent with the rules. I do not feel you have explained *why* you find these types "incompatible" (the rules only talk about direct compatibility as one option). You have just asserted they are so. But i also don't really have a strong desire to argue about TBAA, as people often do not agree on the answers. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170819/cf1ab8d7/attachment.html>