[PATCH] D19236: Add DITypeIndex for CodeView and emit it for locals

[David Blaikie via llvm-commits]

On Thu, Apr 21, 2016 at 8:20 AM, Amjad Aboud via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> aaboud added a comment.
>
> Hi Reid,
> Thanks for the answers, now as I understand more your plan, I have more
> questions:
>
> 1. You want to use indices into list of MDString per CU to improve LTO
> linkage and reduce type footprint by improving merging types from different
> compile unites. right? 1.a. I claim that we can achieve that by doing a
> deep compare on current debug info metadata (based DWARF), do you agree?
>

I don't believe the goal is to improve LTO here - the goal is to implement
CodeView debug info & the argument is that we've generally wanted to reduce
type size/processing cost by doing more of it up-front rather than
generating another intermediate representation & then processing that down
in LLVM. CodeView happens to be an opportunity to experiment with that
route - rather than adding all the extra semantic information to the
metadata format to support CodeView type emission, instead we're going to
build it up-front to test out the idea of doing up-front type emission in
general (but we're not going to port DWARF over immediately, but possibly
some time in the future).


> 2. Regarding the MDString, it should be generated canonically, otherwise
> the compare will fail, right?


Which comparison? The plan here is not to have a trivial string comparison
for types. The merging of types under LTO, if and when it's implemented,
would involve knowledge of the CodeView file format. The initial
implementation will do no merging at LTO time and each CU will retain its
static blob of CodeView type information. When emitting that to the final
object file, merging/renumbering may take place.


> 2.a. Can you give example on what it will contain for class types? 2.b. I
> claim that we can generate that MDString today by traveling on "DI*Type"
> entries (based dwarf), do you agree or you think that we already lost some
> information?


We've already lost some information - that's the initial motivation here.
If the DI*Type hierarchy  already had all the information needed for
CodeView types, we'd probably just implement it that way today & leave the
up-front type emission experiment for another day.


> 2.c. I assume you will still need to generate "DI*Type" entries for
> compound types (maybe with the index into the MDString list), as you cannot
> get all information from the MDString, can you?


Not sure I understand the question - for CodeView, /all/ type information
(especially, but not exclusively, for compound types) will be in one blob
of static data per CU.


> 2.d. Do you have estimation on how much size the "llvm.dbg.cvtypes" will
> consume? Can you assure we will end up reducing the IR size and not
> increasing it?
> 3. If the idea is to reduce the size of the LTO IR, why we are not doing
> this also for DWARF, why just for CV types?
>

Because that's a lot of work that's not needed right now. Right now the
need is to emit CodeView debug info. The goal is to use the motivation here
to experiment with something we've been considering for a while and, if it
seems like a good path forward we can port DWARF over to it at some point
in the future when someone decides they want to save a few more bytes and
cycles.

- David


>
> Thanks,
> Amjad
>
>
> http://reviews.llvm.org/D19236
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160421/35f1ca23/attachment.html>