[llvm-dev] RFC: Resolving TBAA issues

[Daniel Berlin via llvm-dev]

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