rjmccall added a comment. In https://reviews.llvm.org/D31885#730853, @hfinkel wrote:
> > 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. > > Okay, so the problem right now is that we're **not** conservative regarding > union type punning, and while BasicAA sometimes fixes this for us, it doesn't > always, and can't always, and so now we're miscompiling code. I agree that BasicAA "can't always", but I'm not sure it "can't often enough". Again, it seems to me that the low-level problem is just that the AA interface isn't designed for what we're trying to do with TBAA. "MayAlias" is the default answer for everything that can't be proven one way or the other, and "MustAlias" demands that the memory be actually known to overlap. If there were an intermediate "LikelyAlias" for pointers that are known to be related but BasicAA just doesn't know for certain whether the accesses overlap, then TBAA would turn itself off in those cases as long as at least a basic value-propagation pass has been run. That would put us on much firmer ground to say "it's reasonable for the compiler to assume that these things don't alias, and if you're going to use type-punning like this, you just need to rewrite your code to make it more obvious that the pointers are related". When you're given a language rule as weak as this, especially one that's so frequently violated, that's the only kind of argument which is going to have any traction with users. 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
