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

We would need to access the LLVM debug metadata type information directly from
LLVM types.  It looks like the current clang and llvm-gcc don't support such
an association, nor appears the LLVM itself do.   (We are tracking TOT, but only
once a month or so.)

In terms of LLVM IR, apparantly this would simply mean optionally adding another
metadata value to each type.  For example, let us have a C type

  struct T { int a };

In LLVM IR (with no name conflicts), this get presented as 

  %struct.T = type { i32 }

Now, we would like to annotate this with a piece of metadata, something like
this:

  %struct.T = type { i32 }, !dbg !11

with the associated metadata being something like the following:

!1 = metadata !{i32 524329, metadata !"foo.c", metadata
!"/tmp", metadata !2} ; [ DW_TAG_file_type ]
!2 = metadata !{i32 524305, i32 0, i32 12, metadata !"foo.c", metadata
!"/tmp", metadata !"clang version 2.9 ($URL$)", i1 true, i1
false, metadata !"", i32 0} ; [ DW_TAG_compile_unit ]
!5 = metadata !{i32 524324, metadata !1, metadata !"int", metadata !1,
i32 0, i64 32, i64 32, i64 0, i32 0, i32 5} ; [ DW_TAG_base_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 ]
!12 = metadata !{metadata !13}
!13 = metadata !{i32 524301, metadata !1, metadata !"a", metadata !1,
i32 2, i64 32, i64 32, i64 0, i32 0, metadata !5} ; [ DW_TAG_member ]

Then the type would probably need to be added to a new named metadata tag as
well, maybe !llvm.dbg.ty?

Would the right starting point be to simply add an MDNode pointer to the Type
class?  That should be then convertible to a DIType?

The next step apparently would be to support to LLParser to read in such
associations, and to AsmPrinter to print it out.  But how about the bitcode? 
Would this require a new LLVMBitCode?

With that, would LLVM be able to deal with the type-associated metadata, or is
there something in the LLVM side that I'm missing?

Once that works, I guess I need to ask how to extend clang to emit the
information, but the right place for that would be cfe-dev, wouldn't it?

--Pekka Nikander

On Sep 29, 2010, at 4:30 AM, Pekka Nikander wrote:
> We would need to access the LLVM debug metadata type information directly
from LLVM types.  It looks like the current clang and llvm-gcc don't support
such an association, nor appears the LLVM itself do.
True. I am curious how do you want to use this association ?
> 
> Then the type would probably need to be added to a new named metadata tag
as well, maybe !llvm.dbg.ty?
This is a preferred way to do. BTW, I used llvm.dbg.ty name so it is a good idea
to pick up some name that also conveys your use of this association.
> 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}
> 
> The next step apparently would be to support to LLParser to read in such
associations, and to AsmPrinter to print it out.
Yes.
>  But how about the bitcode?  Would this require a new LLVMBitCode?  
You need to modify bitcode writer/reader.
> 
> With that, would LLVM be able to deal with the type-associated metadata, or
is there something in the LLVM side that I'm missing?
Yes. BTW, Dan Gohman is working on TBAA. He is also working on necessary support
to associate Type with a metadata.
> Once that works, I guess I need to ask how to extend clang to emit the
information, but the right place for that would be cfe-dev, wouldn't it?
yes.
-
Devang

On Sep 29, 2010, at 10:05 AM, Devang Patel wrote:
> 
> On Sep 29, 2010, at 4:30 AM, Pekka Nikander wrote:
> 
>> We would need to access the LLVM debug metadata type information
directly from LLVM types.  It looks like the current clang and llvm-gcc
don't support such an association, nor appears the LLVM itself do.
> 
> True. I am curious how do you want to use this association ? 
Be aware that types are uniqued and that the IR name is completely meaningless.

-Chris

>> We would need to access the LLVM debug metadata type information
directly from LLVM types.  It looks like the current clang and llvm-gcc
don't support such an association, nor appears the LLVM itself do.
> 
> True. I am curious how do you want to use this association ? 
Thanks for you advice below, Devang.

We are using LLVM type definitions + debug metadata to interpret binary data,
read from memory, and dump it out as LLVM IR constants.  A similar kind of thing
to what GNU Emacs does when it dumps its memory image when bootstrapping, or
what some OSes do to speed up their boot times on a known hardware
configuration.  However, our approach is different in that we want to have an
LLVM IR dump, not a binary dump as emacs and the OSes do.

In our case, the data structures we are dumping are ones that are configured
when the original program is initialised, and then not changed afterwards; we
are essentially producing frozen configurations.  Then we optimize the
performance critical part of the original program with a frozen configuration
(instead of using a dynamically assembled configuration).  The results from our
prototyping so far are pretty good; in some cases we are able to repeatedly
perform loop peeling and constant propagation so that the original loop
disappears altogether.  (We didn't get constant propagation to go through
the PHIs our loops initially have.  Peeling the loop helped.)

Using @llvm.invariant.start doesn't give as good results, since from our
dump we know the exact value of the data fields, in addition to that they
don't change.  Hence, that allows us to optimise the code much more
aggressively.

And yes, (to Chris in the other e-mail), we are aware that the IR type names are
"meaningless".  That's the main reason why we want to use the
debug metadata, under the assumption that it would have better coherence with
the source code.
>> Then the type would probably need to be added to a new named metadata
tag as well, maybe !llvm.dbg.ty?
> 
> This is a preferred way to do. BTW, I used llvm.dbg.ty name so it is a good
idea to pick up some name that also conveys your use of this association.
Would !llvm.dbg.types be appropriate?  Are there naming conventions here?
>> 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...  
> Yes. BTW, Dan Gohman is working on TBAA. He is also working on necessary
support to associate Type with a metadata.
Thanks for the hint.  Our goal seems to be orthogonal, though, I think.

--Pekka