[LLVMdev] [proposal] Extensible IR metadata

Devang Patel devang.patel at gmail.com
Mon Sep 14 17:55:11 PDT 2009


On Fri, Sep 11, 2009 at 1:20 PM, Jeffrey Yasskin <jyasskin at google.com> 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);

IMO, there is not any need to add two llvm::Instruction  methods,
getMD and setMD. The metadata associated with an instruction will be
store separately anyway.
-
Devang

>
> 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
> executions.
>
> 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
> problem.
>
> Thoughts?
>
> 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
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
-
Devang




More information about the llvm-dev mailing list