[llvm-dev] RFC: Drop support for old style scalar TBAA
Sanjoy Das via llvm-dev
llvm-dev at lists.llvm.org
Mon Nov 7 13:01:45 PST 2016
I want to clarify / emphasize two things based on an off-list
- The bitcode and IR parser both auto upgrade old style TBAA to the
newer TBAA struct tags. So, for instance, if you're writing out IR
to disk with the old representation and reading it back in then the
auto-upgrade logic will do the right thing for you. You do *not*
need to do anything special here. However, I'd still appreciate it
if can give me a thumbs-up or thumbs-down after doing some basic
sanity testing with D26229 applied locally.
- You'll only be affected by this change if you're creating IR in
memory (for instance via the IRBuilder interface), use the old TBAA
metadata representation and don't have an intermediate IR or
bitcode parsing step that would have auto-upgraded the IR. In this
case, the quickest way to keep your frontend working with the new
representation is to change
llvm::UpgradeTBAA is present on tip-of-tree. If your version of
LLVM is too old to have that utility then copy/pasting it in from
tip-of-tree into your code base should work fine.
Sanjoy Das wrote:
> In https://reviews.llvm.org/D26229 I've proposed dropping support for
> old style scalar TBAA metadata.
> Here is the proposed commit message:
> "We've had support for auto upgrading old style scalar TBAA access
> metadata into the "new" struct path aware TBAA metadata for 3 years now.
> The only way to actually generate old style TBAA was explicitly through
> the IRBuilder API. I think this is a good time for dropping support for
> old style scalar TBAA."
> Are there active users of LLVM who _need_ the old style scalar TBAA and
> cannot use the new struct path TBAA metadata? If so, or if you object
> the change for other reasons, please respond here.
> The motivation here is to reduce complexity in our TBAA analysis if
> -- Sanjoy
More information about the llvm-dev