[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#730072, @rjmccall wrote:

> Thanks for CC'ing me.  There are two problems here.
>
> The second is that our alias-analysis philosophy says that the fact that two accesses "sufficiently obviously" can alias should always override TBAA.


I'm not sure i agree.
We have made explicit exceptions for parts of the standard that are nonsensical (and they've been slowly updated in newer standards to be less nonsensical).  Outside of that, i don't believe that is our philosophy, nor would i believe it should be.
There is no "do what i mean" here we can define that makes sense.

>   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.

Just to note: Even assuming this wasn't crazytown, we certainly can't do it in  the backend :)

The answer in such a case is to disable TBAA on those accesses and not emit it.
That is the direction we are moving, because trying to implement any rule about what "sufficiently obvious" means in the backend is a losing game.
It has no idea what it is doing, nor can it.
TBAA in the backend is a misnomer.
It is just walking a tree of hierarchical sets.   It has literally no idea what any of those sets mean, nor should it.

> John.




Repository:
  rL LLVM

https://reviews.llvm.org/D31885