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

Pete Cooper peter_cooper at apple.com
Mon Nov 10 12:48:21 PST 2014


> On Nov 10, 2014, at 11:57 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> 
>> 
>> 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”.
Good point.
> 
>> 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.
Sounds good.
> 
> 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.
Totally agree with this approach.  Whether or not separating debug info out from metadata is a good idea can definitely wait til later, and may not be needed at all.

Cheers,
Pete

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141110/a5f007d1/attachment.html>


More information about the llvm-dev mailing list