llvm dev - Nov 2016 - RFC: Drop support for old style scalar TBAA

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

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

Seems like a nice cleanup to me!
> On 2016-Nov-07, at 13:01, Sanjoy Das via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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.
Shouldn't we drop the textual IR auto-upgrade?  I'd rather fail in the
verifier, since we don't aim for textual IR compatibility anyway.  (Could be
done as follow-up, and it would be nice to attach an upgrade script to a PR or
on the list or something.)
>  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
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev