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

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

On Tue, Nov 8, 2016 at 8:31 AM, Duncan P. N. Exon Smith
<dexonsmith at apple.com> wrote:
> 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.)
Honestly, the upgrade code is simple enough that I don't think it's a
net win to delete.

What I can do is make the textual IR tbaa auto-upgrade controlled by
an off by default option.  That way you get the stricter behavior by
default but you can flip back to the gentler behavior if you'd rather
not edit all your IR files now.

What do you think?
-- Sanjoy

> On 2016-Nov-08, at 12:14, Sanjoy Das <sanjoy at
playingwithpointers.com> wrote:
> 
> On Tue, Nov 8, 2016 at 8:31 AM, Duncan P. N. Exon Smith
> <dexonsmith at apple.com> wrote:
>> 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.)
> 
> Honestly, the upgrade code is simple enough that I don't think it's
a
> net win to delete.
It's more for the principle than anything else... it's inconsistent to
support upgrading some things and not support upgrading others.
> What I can do is make the textual IR tbaa auto-upgrade controlled by
> an off by default option.  That way you get the stricter behavior by
> default but you can flip back to the gentler behavior if you'd rather
> not edit all your IR files now.
> 
> What do you think?
I'm strongly against adding an option.  But otherwise I'm not too
concerned about this.  Feel free to leave the upgrade path in if you think
it's valuable; we can always remove the cruft later.