[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