hfinkel added a comment. I'm not sure this is the right way to do this; I suspect we're lumping together a bunch of different bugs:
1. vector types need to have tbaa which makes them alias with their element types [to be clear, as vector types are an implementation extension, this is our choice; I believe most users expect this to be true, but I'm certainly open to leaving this as-is (i.e. the vector types and scalar types as independent/non-aliasing)]. 2. tbaa can't be used for write <-> write queries (only read <-> write queries) because the writes can change the effective type 3. our 'struct' path TBAA for unions is broken (and to fix this we need to invert the tree structure, etc. as discussed on the list) (1) and (3) are independent bugs. (1) if desired, should just be fixed (the vector type should be a child of the scalar element type in the current representation). (2) needs to be fixed too, is not strictly related to unions, and needs to be fixed in the backend. Doing this does not seem hard (we just need to record a Write Boolean in MemoryLocation and then check them in TypeBasedAAResult (TBAA can't be used if both locations are writes). (3) is what this should address. What we should do here is only generate the scalar TBAA for the union accesses. As I recall, the only reason that the scalar TBAA for union accesses is a problem is because of (2), but that's easy to fix in the backend (and we need to do that anyway). @dberlin , do you agree? 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
