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

Sat May 1 02:25:16 PDT 2021

nikic added a comment.

In D101185#2716977 <https://reviews.llvm.org/D101185#2716977>, @fhahn wrote:

> On a high level, encoding more Clang specifics into the `tbaa` spec and using it as heuristics seems a bit unfortunate to me, as it may pessimize frontends that for various reasons cannot use `tbaa`, especially because the additional information does not seem `tbaa` specific to me.
>
> I understand it is very convenient to use `tbaa` in this case, but I am worried about non-Clang frontends once this heuristic becomes important for performance. What will we suggest to frontends that want to opt-in to the optimizations (but `tbaa` in general is not suitable for them)?

This is also my concern. It would be very helpful is somebody familiar with TBAA could clarify whether there is any way to add the necessary metadata without having an effect on aliasing. I don't think it's possibly to just disable the TBAA analysis, because the optimization pipeline is generally not under your control (in cross-language linker-plugin LTO scenarios).

>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?

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.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101185