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

On Sep 30, 2010, at 1:30 AM, Pekka Nikander wrote:
>>>> Would the right starting point be to simply add an MDNode
pointer to the Type class?  That should be then convertible to a DIType?
>>> 
>>> We want to avoid any Type class modification. Instead you can use
pair in named metadata to match metadata with type.
>>> 
>>> !11 = metadata !{i32 524307, metadata !1, metadata !"T",
metadata !1, i32 2, i64 32, i64 32, i64 0, i32 0, null, metadata !12, i32 0,
null} ; [ DW_TAG_structure_type ]
>>> 
>>> !21 = metadata !{ metadata !11,  %struct.T %z}
>>> 
>>> !llvm.my_special_type_info = !{!21}
>> 
>> Ok, that approach should work.  Though we want to associate the type,
not some variable with the type, i.e. something like
>> 
>> !21 = metadata !{ %struct.T, metadata !11 }
>> 
>> But I don't know if that would be valid syntax...  
> 
> I thought about that more, and I think the "right" way would be
to have a syntax like
> 
> !21 = metadata !{ type %struct.T, metadata !11 } 
> 
> or perhaps
> 
> !21 = metadata !{ typeval %struct.T, metadata !11 }
> 
> to avoid the problem with the keyword 'type'.
> 
> But to be able to do that, should apparently be possible to represent types
as first class values.  That in turn would apparently require a new
Type::TypeID?
> 
> Would that be worth doing?  Apparently we can fake with our need, and use a
null pointer instead.  Technically, that would be wrong, but would work with the
current code without any modifications:
> 
> !21 = metadata !{ %struct.T *null, metadata !11 }
I would recommend this approach.

-
Devang
> 
> Any opinions?  (I guess I'll just try the number of changes needed for
a 'typeval' and report back.)
> 
> --Pekka
>

>>>> We want to avoid any Type class modification. Instead you can
use pair in named metadata to match metadata with type.
>>>> 
>> 
>> I thought about that more, and I think the "right" way would
be to have a syntax like
>> 
>> !21 = metadata !{ type %struct.T, metadata !11 } 
>> 
>> or perhaps
>> 
>> !21 = metadata !{ typeval %struct.T, metadata !11 }
>> 
>> to avoid the problem with the keyword 'type'.
>> 
>> Would that be worth doing?  Apparently we can fake with our need, and
use a null pointer instead.  Technically, that would be wrong, but would work
with the current code without any modifications:
>> 
>> !21 = metadata !{ %struct.T *null, metadata !11 }
> 
> I would recommend this approach.
But that would have a hacky feeling :-)

Anyway, I already implemented an early patch for making Types representable as
Values.  For that I created a new class, TypeValue, which represents a type as a
value.  An early patch for that enclosed.  Works when reading or writing textual
representations; no BC representation yet.  And no test case yet.

This works well enough for our purposes; I don't have any incentive to go
further unless someone else needs a similar kind of functionality.

--Pekka

-------------- next part --------------
A non-text attachment was scrubbed...
Name: TypeValue.diff
Type: application/octet-stream
Size: 11238 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100930/eead66b4/attachment.obj>

>>> I thought about that more, and I think the "right" way
would be to have a syntax like
>>> 
>>> !21 = metadata !{ typeval %struct.T, metadata !11 }
>>> 
>>> to avoid the problem with the keyword 'type'.
>>> 
> 
> Anyway, I already implemented an early patch for making Types representable
as Values.  For that I created a new class, TypeValue, which represents a type
as a value.  An early patch for that enclosed.  Works when reading or writing
textual representations; no BC representation yet.  And no test case yet.
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.

--Pekka

-------------- next part --------------
A non-text attachment was scrubbed...
Name: TypeValue.diff
Type: application/octet-stream
Size: 16812 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101005/93446e93/attachment.obj>

I'd really be interested in getting full support for this.
We're doing abstract interpretation on c++  code (lowered to c code via 
llvm).
I restrained from adding a direct mapping from type to type name because 
it appears to be somewhat
involved (having to change the IT etc) but it would be very helpful for 
us to have this.

Alex

P.S.: To Devang : I'll submit the other patch for debug info asap..I 
just didn't have the time yet..



On 09/30/2010 07:28 PM, Pekka Nikander wrote:
>>>>> We want to avoid any Type class modification. Instead you
can use pair in named metadata to match metadata with type.
>>>>>
>>>>>            
>>> I thought about that more, and I think the "right" way
would be to have a syntax like
>>>
>>> !21 = metadata !{ type %struct.T, metadata !11 }
>>>
>>> or perhaps
>>>
>>> !21 = metadata !{ typeval %struct.T, metadata !11 }
>>>
>>> to avoid the problem with the keyword 'type'.
>>>
>>> Would that be worth doing?  Apparently we can fake with our need,
and use a null pointer instead.  Technically, that would be wrong, but would
work with the current code without any modifications:
>>>
>>> !21 = metadata !{ %struct.T *null, metadata !11 }
>>>        
>> I would recommend this approach.
>>      
> But that would have a hacky feeling :-)
>
> Anyway, I already implemented an early patch for making Types representable
as Values.  For that I created a new class, TypeValue, which represents a type
as a value.  An early patch for that enclosed.  Works when reading or writing
textual representations; no BC representation yet.  And no test case yet.
>
> This works well enough for our purposes; I don't have any incentive to
go further unless someone else needs a similar kind of functionality.
>
> --Pekka
>
>    
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101006/4ab3d349/attachment.html>