<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 21, 2016 at 8:20 AM, Amjad Aboud via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">aaboud added a comment.<br>
<br>
Hi Reid,<br>
Thanks for the answers, now as I understand more your plan, I have more questions:<br>
<br>
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?<br></blockquote><div><br></div><div>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).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Regarding the MDString, it should be generated canonically, otherwise the compare will fail, right?</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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?</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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?</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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?<br>
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?<br></blockquote><div><br></div><div>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.<br><br>- David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Amjad<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<a href="http://reviews.llvm.org/D19236" rel="noreferrer" target="_blank">http://reviews.llvm.org/D19236</a><br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>