[llvm-dev] RFC: Resolving TBAA issues

[Daniel Berlin via llvm-dev]

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/2158b238/attachment.html>