[PATCH] D31885: Remove TBAA information from LValues representing union members

[Daniel Berlin via Phabricator via cfe-commits]

dberlin added a comment.

In https://reviews.llvm.org/D31885#727352, @hfinkel wrote:

> > I'm not sure about the solution to #2, because i thought there were very specific points in time at which the effective type could change.
>
> I think this is a key point. I'm not sure that there are specific points that the frontend can deduce:
>
>   union U {
>     int i;
>     float f;
>   };
>   
>   void bar1(int *i) {
>     *i = 0; // we just reset the type here
>   }
>   
>   void bar2(float *f) {
>     *f = 0.0f; // we just reset the type here too
>   }
>   
>   void foo(U *u) {
>     bar1(&u->i);
>     bar2(&u->f);
>   }
>   
>
> Even if the union has structs instead of scalar types, I'm not sure that changes the situation. There certainly are situation where you can't silently change the types of objects in C++ just by starting to write a to differently-typed object at the same location, but I think that using this property relies on having some lifetime information for the objects in question, and so AA would need to be able to use this lifetime information to do more. This seems like an orthogonal issue (i.e. we can always add TBAA write <-> write ability in the presence of such lifetime information as an additional feature). Maybe I'm missing something...


Union type accesses must explicitly be made through a union if you want the effective type to change.
This is now actually codified in either c11 or c++14 (i can't remember which), but even before that, it's the only thing gcc/llvm have *ever*  guaranteed.

If you don't make it an explicitly visible union access at each point, you will get wrong code, and this is pretty much unsolvable in general if you want tbaa to work at all.

Because otherwise foo, bar1, and bar2 could all be in different translation units, in which case, you just destroyed all usefulness of tbaa because it has to assume all pointers can conflict with all pointers :)


Repository:
  rL LLVM

https://reviews.llvm.org/D31885