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:
Seems like a nice cleanup to me!
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
Seems like a nice cleanup to me!
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.