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

[Daniel Berlin via Phabricator via cfe-commits]

dberlin added a comment.



> Your proposal to we simply drop TBAA from all accesses related to unions is extremely conservative.  It means that an access through a union has to be treated as potentially aliasing every other visible access, at least in terms of their types.  That level of conservatism is not necessary in this case if we hew to the original understanding of LLVM's TBAA that punning is only allowed when it is sufficiently obvious.  If you are interested in making a strict definition of "sufficiently obvious", and then arguing that it cannot possibly work, we can have that conversation; but right now I'm not seeing anything that says that our approach is basically broken, other you repeatedly asserting it because you think TBAA should be capable of completely standing alone.

Did you look at the large number of bugs that prompted this patch and discussions on the mailing list?

> My proposal is that (1) we should correctly encode the aliasability of vector types in TBAA metadata and, separately, (2) we should also ensure that TBAA is correctly overridden by BasicAA in this case, which may require introducing an intermediate level of response between MayAlias and MustAlias.

How do you see #2 working?
RIght now, it is overridden if TBAA says no-alias and basicaa says must-alias.

It's quite literally not possible for basicaa to detect all cases it should override.  If you want paper references on the strict breakdown of what can be decided statically, i'm happy to provide them.
Otherwise, there are plenty of bugs filed with real-world examples already.
So it doesn't now, it can't in the future.  This is the source of a number of those bugs.
If BasicAA could prove no-alias, it wouldn't' need to override, so you can't just override any may-alias cases.  It can't detect all must-aliasing, or even anything approaching them.  
It doesn't work in probabilities, and llvm's type system is unrelated to the C level one, so it can't even flag those things that might be "bad", so there is nothing it can answer in between.
This opposed to doing it in the front end, where it knows *all* of this, and could simply stop telling the backend two things don't alias when you want it to do that.

So i'd like to understand how you see it "correctly overriding in BasicAA". 
There is *nothing*, in any of these accesses or examples, at the LLVM IR level, that tells us we should override it.


Repository:
  rL LLVM

https://reviews.llvm.org/D31885