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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
