[PATCH] D122573: [TBAA] Emit distinct TBAA tags for pointers with different depths,types.

Tue Mar 29 09:50:39 PDT 2022

fhahn added a comment.

In D122573#3412109 <https://reviews.llvm.org/D122573#3412109>, @rjmccall wrote:

> Hmm.  We know that the big picture here, distinguishing pointers by pointee type, is going to be disruptive and will probably need a specific enabling/disabling option.  I'm not sure that distinguishing only by pointer depth is a minor enough step that it shouldn't be treated the same way; in particular, it's going to start treating `void *` as incompatible with e.g. `char **`.

@rjmccall do you have any suggestions how to further reduce the initial step?

In D122573#3413445 <https://reviews.llvm.org/D122573#3413445>, @xbolva00 wrote:

> Can you provide some flag?

It should be controlled by the existing `-fno-strict-aliasing`  flag, but there should probably be a dedicated flag as well to opt in the additional annotations.

In D122573#3412233 <https://reviews.llvm.org/D122573#3412233>, @efriedma wrote:

> I'm a little skeptical about making TBAA more aggressive.  In most situations, we're probably talking about tiny performance gains, and currently there's no good way to check whether a codebase suffers from type punning issues (either with compile-time analysis or runtime instrumentation).  Probably LLVM itself does, but we have no way of knowing.

Agreed, strict aliasing violations are already a problem with the current level of TBAA support and we regularly see mis-compiles when new optimizations get enabled due to violations in projects. Improving precision of TBAA annotation is likely to expose more violations But there are cases where the additional guarantees could make a difference and other compiler implementations make use of them, so I think it would be worthwhile to work towards improving TBAA. I think we've also been through other disruptive transitions, like more aggressively adding `mustprogress`, but those were probably on a somewhat smaller scale.

Maybe we should try improve our tooling to detect violations in parallel to the effort in this patch? I am planning on trying to resurrect the type-sanitizer patches. I've also been playing around with a simple tool that's inserting assertions to check 2 pointers are not equal if TBAA claims they are no alias. The latter seems to surface a few violations in code in `llvm-test-suite` and also in tablegen. That is even without the current patch applied.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122573/new/

https://reviews.llvm.org/D122573