[LLVMdev] [proposal] Extensible IR metadata
David Greene
dag at cray.com
Fri Sep 11 15:23:57 PDT 2009
On Friday 11 September 2009 15:20, Jeffrey Yasskin wrote:
> I've got a suggestion for a refinement:
>
> Right now, we have classes like DILocation that wrap an MDNode* to
> provide more convenient access to it. It would be more convenient for
> users if instead of
>
> MDNode *DbgInfo = Inst->getMD(MDKind::DbgTag);
> Inst2->setMD(MDKind::DbgTag, DbgInfo);
>
> they could write:
>
> DILocation DbgInfo = Inst->getMD<DILocation>();
> inst2->setMD(DbgInfo);
>
> we'd use TheContext->RegisterMDKind<MyKindWrapper>() or
> ...Register<MyKindWrapper>("name"); to register a new kind. (I prefer
> the first.)
Yes, this is very convenient. This along with the rest of Chris' proposal is
very similar to the way we handled metadata in a compiler I worked on years
ago. It was so useful we even used it to stash dataflow information away as
we did analysis. Of course we had metatadat tagged on control structures as
well. I'd like to see the currently proposal extended to other constructs as
Chris notes.
> StaticTypeId is a new class that maps each of its template arguments
> to a small, unique integer, which may be different in different
> executions.
How does this work across compilation units? How about with shared LLVM
libraries? These kinds of global unique IDs are notoriously difficult
to get right. I'd suggest using a third-party unique-id library. Boost.UUID
is one possibility but not the only one.
I have a few questions and comments about Chris' initial proposal as well.
- I don't like the separation between "built-in" metadata and "extended"
metadata. Why not make all metadata use the RegisterMDKind interface and
just have the LLVM libraries do it automatically for the "built-in" stuff?
Having a separate namespace of enums is going to get confusing. Practically
every day I curse the fact that "int" is different than "MyInt" in C++. :-/
- Defaulting alignment to 1 when metatadata is not present is going to be a
huge performance hit on many architectures. I hope we can find a better
solution. I'm not sure what it is yet because we have to maintain safety.
I just fear a Pass inadvertantly dropping metadata and really screwing
things up.
This looks very promising!
-Dave
More information about the llvm-dev
mailing list