<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 21, 2016 at 2:31 PM, Aboud, Amjad <span dir="ltr"><<a href="mailto:amjad.aboud@intel.com" target="_blank">amjad.aboud@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I am not convinced that you are going the right direction.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Not only that, now you are confusing me with the double motivation, I asked you before on the proposal of improving debug info if the motivation was CodeView
 and you said “no”.</span></p></div></div></blockquote><div><br></div><div>CodeView is the proximal/immediate motivation for the work. The choice of work is motivated by what we think will be a good overall direction.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Now, you claim that the motivation is fast implementation for CodeView.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I think it is easier/faster/doable to emit CodeView from current Dwarf Metadata,</span></p></div></div></blockquote><div><br></div><div>Not currently, we'd have to do a bunch of work to plumb through more information into the DWARF metadata scheme. The argument is that that's the tipping point to trying something different - that there's enough engineering work there that we think, in the long run, would be obsoleted by doing an up-front emission, that we should just start putting work behind that instead.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> for sure more than you will be able to do with the Blobs/MDStrings that you do
 not explain yet how it will look like.</span></p></div></div></blockquote><div><br></div><div>I'm not sure I understand this ^ statement, sorry.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">I can simply let you commit this patch that adds nothing to what we can do today, but you will need to prove that the next patch (when you support compound types)
 will work more than we can implement today with what we have in dwarf.</span></p></div></div></blockquote><div><br></div><div>I think it's already been covered in the RFC, etc, the sort of information required for the Windows ABI (moreso in terms of complexity/differences in the way runtime polymorphism is implemented (quite different from Itanium - different constructs that need to be described, etc)) is substantially different in enough ways from Itanium that it cannot be implemented with the existing DWARF metadata - the DWARF Metadata schema describes Itanium ABI constructs, not Windows ABI constructs.<br><br>Yes, we could add them to the DWARF Metadata and hold both (or a union where one or the other is provided), but the bet is that all the extra complexity would eventually be removed anyway as we eventually migrate to up-front emission. So we might as well get started on that now, rather than do a bunch of work we'll throw out anyway.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">If your approach will fail, will you consider revert and go back to one representation of debug info (Dwarf based or whatever) and do the simple extra work in
 the backend to emit the format needed by the target?</span></p></div></div></blockquote><div><br></div><div>If it turns out this path is unachievable (though we really have a pretty good basis to believe it's achievable - it's essentially the architecture Microsoft's compiler uses and the way the CodeView format is designed to handle type information) I'm sure we'll re-evaluate about what the right path forward is. Depending on why it's unachievable, maybe the answer will be to extend the existing metadata type schema with the extra information, maybe it'll be something else. I expect we'll cross that river should we come to it.<br><br>- David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Thanks,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Amjad<u></u><u></u></span></p>
<p class="MsoNormal"><a name="m_-8306700829183679303__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><a name="m_-8306700829183679303______replyseparator"></a><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Reid Kleckner [mailto:<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>]
<br>
<b>Sent:</b> Thursday, April 21, 2016 23:44<br>
<b>To:</b> David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>><br>
<b>Cc:</b> <a href="mailto:reviews%2BD19236%2Bpublic%2Bb02ee3c2b2d2b281@reviews.llvm.org" target="_blank">reviews+D19236+public+b02ee3c2b2d2b281@reviews.llvm.org</a>; Aboud, Amjad <<a href="mailto:amjad.aboud@intel.com" target="_blank">amjad.aboud@intel.com</a>>; Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>>; Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>>; Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>>; llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>><br>
<b>Subject:</b> Re: [PATCH] D19236: Add DITypeIndex for CodeView and emit it for locals<u></u><u></u></span></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">On Thu, Apr 21, 2016 at 10:45 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">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?<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Yes, thanks for writing that! That's a good way to put it: collectively, we think emitting debug types in the frontend is the right design long term, for both coupling and efficiency reasons. Doing it for DWARF is a large amount of work,
 and nobody has immediate plans to do it. CodeView, however, does need work, and this is a good opportunity to experiment with up front type emission.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I meant to respond to the RFC with something along those lines, but writing patches is so much more attractive than writing email...<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div></div></div>
</div>
<p>---------------------------------------------------------------------<br>
Intel Israel (74) Limited</p>

<p>This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.</p></div>

</blockquote></div><br></div></div>