[LLVMdev] [RFC] Separating Metadata from the Value hierarchy

Duncan P. N. Exon Smith dexonsmith at apple.com
Mon Nov 10 11:57:12 PST 2014


> On 2014-Nov-10, at 11:05, Pete Cooper <peter_cooper at apple.com> wrote:
> 
> 
>> On Nov 10, 2014, at 10:17 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>> 
>> The class hierarchy I envision looks something like this:
>> 
>>    Metadata
>>      MDNode
>>        TempMDNode      // MDNodeFwdRef?
>>        UniquableMDNode // GenericMDNode?
>>        DINode          // Is this layer useful?
>>          DILocation
>>          DIScope
>>            DIType
>>              DIBasicType
>>              DICompositeType
>>              ...
>>            DISubprogram
>>            ...
>>          DICompileUnit
>>          ...
>>      MDString
>>      ValueAsMetadata   
> Why not just make the Debug classes totally first class, i.e., the root of their own hierarchy?  Given that you’re removing local metadata, fixing up dbgvalue, and debug locations are already stored on instructions in a special way, I don’t see why we need to even represent debug info as metadata at all.

Two reasons jump out:

 1. It's serving as a nice forcing function for cleaning up the rest
    of metadata.

 2. I suspect the rules for "how to deal with debug info" would look
    pretty similar to those for "how to deal with metadata".

> Debug info is already being treated specially in parsing, printing, storage, etc.  Seems like having Module contain a pointer to its CompileUnit(s) would move a huge amount of this stuff completely out of metadata.  Then you can still have your own rules for uniquing if you want them.

Yup, that's the plan, except for the "out of metadata" part.  Once
the hierarchy is fixed I'll create custom types for debug info,
whose ownership (and uniquing where appropriate) I'll customize.  I
agree that a module should own its compile unit(s) directly.

If there's a compelling reason to separate debug info entirely, the
planned work is IMO the right incremental step to get there.  We
need to customize the ownership first.  But cleaning up metadata and
customizing debug info ownership (etc.) could be sufficient.



More information about the llvm-dev mailing list