search for: mdkinds

...ust 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 StaticType...

Devang's work on debug info prompted this, thoughts welcome: http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt -Chris

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 Here is partial initial implementation. Thoughts ? - Devang -------------- next part -------------- A non-text attachment was scrubbed... Name: mdn.diff Type: application/octet-stream

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

On Mon, Nov 30, 2009 at 10:14 AM, Nick Lewycky <nlewycky at google.com> wrote: > What's the memory usage penalty of that on a > large program? I have not measured that yet. > If we're willing to pay this memory cost, even for programs that aren't > using debug info, why not just store pointer to a linked list of metadata > info in the Instruction and remove the