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

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Thanks for CC'ing me.  There are two problems here.

The first is that vectors are aggregates which contain values of their element type.  (And honestly, we may need to be more permissive than this because people are pretty lax about the element type in a vector until it comes time to actually use it.)  We really can't be wishy-washy about casting a pointer-to-vector to a pointer-to-element and manipulating it as an array, or vice-versa — that's an incredibly common part of vector programming.  But even if we wanted to be wishy-washy, there are language features which allow you to drill into a vector and access an element individually, and while you can't take the address of the result, it still generates an access of the element type which obviously aliases the entire vector.  So we need to be modeling that, and hey, if we do that, we'll stop miscompiling this test case and can all go home. :)

The second is that our alias-analysis philosophy says that the fact that two accesses "sufficiently obviously" can alias should always override TBAA.  I have a hard time seeing what about the test cases I'm seeing makes it insufficiently obvious that the accesses alias.  The  accesses are ultimately derived from the same pointer; either the analysis is capable of counting to 32, in which case it should see that they definitely alias, or it is not, in which can it needs to assume that they might.  Perhaps the existing AA interface is just inadequate?  It seems to me that it can't express that middle-ground of "I have a concrete reason to think that these pointers are related but cannot answer for certain whether they overlap".  Because if it could just answer that rather than having to downgrade all the way to MayAlias, it seems clear to me that (1) most memory transforms would treat it exactly the same as MayAlias but (2) it should be considered strong enough to suppress TBAA.

John.


Repository:
  rL LLVM

https://reviews.llvm.org/D31885