[PATCH] D101185: [LangRef] tbaa: type names can be used as hints to optimizations

[Jeroen Dobbelaere via Phabricator via llvm-commits]

jeroen.dobbelaere added a comment.

In D101185#2731194 <https://reviews.llvm.org/D101185#2731194>, @nikic wrote:

> From my reading of LangRef, it might be possible to have a type hierarchy of `"Root" <- "Dummy" <- "any pointer"`, where `"any pointer"` is used to annotate pointer types and `"Dummy"` for anything else. Then aliasing checks between `"Dummy"` and `"any pointer"` will always report aliasing, as it's reachable in one direction. More generally, as long as the type "hierarchy" is a linear chain, no useful aliasing information can be derived. Is that correct? Would this work in practice without causing other complications?

That will indeed work today. One thing that I find annoying with it, is that it feels like 'fighting to not use tbaa', but it is valid and it will have the intended effect.

> I do think what @jeroen.dobbelaere suggests would be the right way to approach this. This doesn't even have to be in addition to `!tbaa.struct`, but can be a replacement for it. In particular, I'm thinking that instead of having an `{offset, size, tbaa}` encoding, it could be `{offset, size, type, tbaa}`, where `type` is some well-defined type indicator to use for this optimization, while `tbaa` is an **optional** TBAA reference for the member. Frontends with type-based aliasing models would populate the last element, frontends without it wouldn't.

Something like that would also work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101185