llvm dev - Oct 2010 - [LLVMdev] Associating types directly with debug metadata?

On Oct 5, 2010, at 11:23 PM, Nick Lewycky wrote:
>> 
>> Here is another version of the patch.  This one includes also a small
patch to llvm-gcc so that it generates the type metadata for structures and
classes.  This one also generates and parses correctly the metadata for .ll
files.  No .bc support yet.  The biggest problem with this version is that it
breaks when the compiler/linker performs type reductions, and I don't
understand why.
> 
> Please don't do this. My objection to the type value is on the grounds 
> that it is not a value. It does not match the conceptual meaning of a 
> value, that is, something you could put in a machine register on some 
> machine.
> 
> If you need to name an LLVM type in your MDNode, just create an undef 
> value of that type.
I agree completely.

-Chris

>>> Here is another version of the patch.  This one includes also a
small patch to llvm-gcc so that it generates the type metadata for structures
and classes.  This one also generates and parses correctly the metadata for .ll
files.  No .bc support yet.  The biggest problem with this version is that it
breaks when the compiler/linker performs type reductions, and I don't
understand why.
>> 
>> Please don't do this. My objection to the type value is on the
grounds
>> that it is not a value. It does not match the conceptual meaning of a 
>> value, that is, something you could put in a machine register on some 
>> machine.
>> 
>> If you need to name an LLVM type in your MDNode, just create an undef 
>> value of that type.
> 
> I agree completely.
Ok, I will try using undefs, but do they work for aggregate types?  Well,
I'll see.

However, I don't understand what is so different in my design from MDNode
and MDString being values?  Sure, I could make the TypeValue a subclass of
MDNode, name it something like MDType, and use a tag different form
"typeval", something like "metatype".  Would that be better?
Or should it still be a direct subclass of Value, like both MDNode and MDString
are?

I tried to carefully model my code after MDNode and MDString, wherever possible.
My intention is to use these from metadata only, after all.

--Pekka

Pekka Nikander wrote:
>>>> Here is another version of the patch.  This one includes also a
small patch to llvm-gcc so that it generates the type metadata for structures
and classes.  This one also generates and parses correctly the metadata for .ll
files.  No .bc support yet.  The biggest problem with this version is that it
breaks when the compiler/linker performs type reductions, and I don't
understand why.
>>>
>>> Please don't do this. My objection to the type value is on the
grounds
>>> that it is not a value. It does not match the conceptual meaning of
a
>>> value, that is, something you could put in a machine register on
some
>>> machine.
>>>
>>> If you need to name an LLVM type in your MDNode, just create an
undef
>>> value of that type.
>>
>> I agree completely.
>
> Ok, I will try using undefs, but do they work for aggregate types?  Well,
I'll see.
>
> However, I don't understand what is so different in my design from
MDNode and MDString being values?  Sure, I could make the TypeValue a subclass
of MDNode, name it something like MDType, and use a tag different form
"typeval", something like "metatype".  Would that be better?
Or should it still be a direct subclass of Value, like both MDNode and MDString
are?
>
> I tried to carefully model my code after MDNode and MDString, wherever
possible.  My intention is to use these from metadata only, after all.
Yes, you make a good point that metadata can't go into a machine 
register; that's a unique property imbued by the 'metadata' type.
There
are still certain axioms that apply to values, such as:

  - all values have a type and a value id that is assigned at creation 
and immutable
  - you can create an undef value of any type (incl. aggregates as you 
asked earlier, but there's also undef metadata)
  - all values have a use-list you can traverse through

It's not clear to me how you would meet those, in particular the second one.

As you proved by example, you could create a TypeValue and LLVM wouldn't 
collapse, but it goes against the grain of the design. If undef will 
work for you, please use it.

Nick