dberlin added a comment. In https://reviews.llvm.org/D31885#727370, @dberlin wrote:
> 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 :) To expand a bit: It's trivial to make the fact that they are in a union invisible. In the above example, assuming you make the union accesses explicit, the union accesses themselves have to *always* conflict with all types in the union , and now you can do that if you know it's a union access., but you couldn't otherwise. IE this is the precise reason that gcc/llvm have required the union accesses be explicit - to associate them with the right tbaa type. Past that, you aren't going to be able to usefully differentiate between the current effective type of a union. There are a few other points where the effective type may change, but i believe the frontend does know about them (IE placement new, etc). Repository: rL LLVM https://reviews.llvm.org/D31885 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
