[llvm-dev] RFC: Drop support for old style scalar TBAA

[Sanjoy Das via llvm-dev]

Hi all,

I want to clarify / emphasize two things based on an off-list
conversation:

  - 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

      I->setMetadata(LLVMContext::MD_tbaa, MD);

    to

      I->setMetadata(LLVMContext::MD_tbaa, llvm::UpgradeTBAANode(*MD));

    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

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
 > feasible.
 >
 > Thanks,
 > -- Sanjoy