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

> In https://reviews.llvm.org/D31885#730539, @dberlin wrote:
>
> > 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.
>
>
> There was a deliberate decision to make TBAA conservative about type punning in LLVM because, in practice, the strict form of TBAA you think we should follow has proven to be a failed optimization paradigm: it just leads users to globally disable TBAA, which is obviously a huge loss.  This was never motivated purely by the nonsensicality of the standardization of unions.


I think you have completely missed my point.  i have not said we should be super strict, i'm saying "there is no DWIM" and "we can't do it in the backend". work.

> (And the nonsensicality of the standard very much continues.  The code that we've all agreed is obviously being miscompiled here is still a strict violation of the "improved" union rules in C++, and if we decide to treat it as ill-formed we're going to break a massive amount of code (and vector code in particular heavily uses unions), because trust me, nobody is reliably placement-newing union fields when they're non-trivial.  C++'s new rules are unworkable in part because they rely on C++-specific features that cannot be easily adopted in headers which need to be language-neutral.)
> 
>>>   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 :)
> 
> Well, thanks for calling me crazy, I guess.

???
I didn't call you crazy, and apologies if you took it that way.
I meant the approach of trying to do it in the backend is crazy and doesn't work.

> John.




Repository:
  rL LLVM

https://reviews.llvm.org/D31885