(and note: It's not clear GCC agrees with my interpretation. I can get it
to seem to answer both ways. Depending on what i do, and looking at
optimizer dumps, i can get it to ignore the access to x->i, and assume it
has no effect on b->a, *and* get it to assume it does, and cause reloads of
x->i)
+Richard in case he has any thoughts.
On Sat, Aug 19, 2017 at 9:00 AM, Daniel Berlin <dberlin at dberlin.org>
wrote:
>
>
> On Sat, Aug 19, 2017 at 6:29 AM, Ivan A. Kosarev via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Daniel, Hal,
>>
>> I'm trying to figure out what we would need to do in terms of the
current
>> approach, accepting its limitations,
>
>
> We don't have to accept the limitations?
> We already know it's pretty trivial to extend it, and we aren't
against
> extending it at all.
>
>
>> to support unions, member arrays, aggregate accesses
>
> and type identifiers and what I get looks suspiciously simple.
>
>
>
>
>> Can you please check it out and let me know if I'm missing
something?
>>
>
>>
>> For aggregate accesses:
>>
>> The comment in TypeBasedAliasAnalysis.cpp suggests:
>>
>> // TODO: We need to check if AccessType of TagA encloses AccessType
of
>> // TagB to support aggregate AccessType. If yes, return true.
>>
>> Consider these two accesses:
>>
>> struct A { int i; };
>> struct B { struct A a; } *b;
>>
>> struct X { int i; } *x;
>>
>> b->a
>> x->i
>>
>> Following the rule in the comment, the accesses are allowed to overlap,
>> which is wrong.
>>
>
> i don't believe this to be wrong in terms of the C/C++ TBAA rules.
>
> C rule:
>
>> An object shall have its stored value accessed only by an lvalue
>> expression that has one of the following types:
>>
>> - a type compatible with the effective type of the object,
>>
>>
>> - a qualified version of a type compatible with the effective type
of
>> the object,
>>
>>
>> - a type that is the signed or unsigned type corresponding to the
>> effective type of the object,
>>
>>
>> - a type that is the signed or unsigned type corresponding to a
>> qualified version of the effective type of the object,
>>
>>
>> - an aggregate or union type that includes one of the aforementioned
>> types among its members (including, recursively, a member of a
subaggregate
>> or contained union), or
>>
>>
>> - a character type.
>>
>>
> 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
>
> These rules are not based on the name of the type, only the types
> contained in the structs.
>
> TBAA cannot distinguish types solely based on name.
>
> C++ is similar:
>
> 3.10.10
>
>> If a program attempts to access the stored value of an object through
a
>> glvalue of other than one of the
>> following types the behavior is undefined:54
>> — the dynamic type of the object,
>> — a cv-qualified version of the dynamic type of the object,
>> — a type similar (as defined in 4.4 ) to the dynamic type of the
object,
>> — a type that is the signed or unsigned type corresponding to the
dynamic
>> type of the object,
>> — a type that is the signed or unsigned type corresponding to a
>> cv-qualified version of the dynamic type
>> of the object,
>> — 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),
>> — a type that is a (possibly cv-qualified) base class type of the
dynamic
>> type of the object,
>> — a char or unsigned char type.
>
>
>
> This is not going to end up with a different result in this case.
>
> Do you agree?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170819/7ededbee/attachment.html>