[LLVMdev] [proposal] Extensible IR metadata

Jeffrey Yasskin jyasskin at google.com
Fri Sep 11 13:20:34 PDT 2009

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>();

we'd use TheContext->RegisterMDKind<MyKindWrapper>() or
...Register<MyKindWrapper>("name"); to register a new kind. (I prefer
the first.)

These kind wrappers need a couple methods to make them work:

const StringRef KindWrapper::name("...");
KindWrapper(MDNode*);  // Except for special cases like LdStAlign.
KindWrapper::operator bool() {return mdnode!=NULL;} // ??
int StaticTypeId<KindWrapper>::value;  // Used for the proposal's MDKind
KindWrapper::ValidOnValue(const Value*);
MDNode* KindWrapper::merge(MDNode*, MDNode*)  // For the optimizers

StaticTypeId is a new class that maps each of its template arguments
to a small, unique integer, which may be different in different

Since the optimizers may want more methods over time, but we don't
really want to require users to extend their wrappers, we should say
that all wrappers must inherit from a particular type. I'd name this
type "MDKind" and rename the proposed MDKind to MDKindID. Then we can
add defaults to MDKind over time. Nothing needs to be virtual since
these types are all used as template arguments.

We could either use a global list of IDs for the MDKinds or have
separate lists for each Context. StaticTypeId can only provide a
global list, so giving each Context its own list would take an extra
lookup, and wouldn't provide any benefit I can see.

Chris mentioned that .bc files would store the mapping from name->ID,
so the fact that StaticTypeId changes its values between runs isn't a


On Fri, Sep 11, 2009 at 9:57 AM, Chris Lattner <clattner at apple.com> wrote:
> Devang's work on debug info prompted this, thoughts welcome:
> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list