<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 22, 2021 at 5:36 PM Alexander Yermolovich <<a href="mailto:ayermolo@fb.com">ayermolo@fb.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
Hello David,<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
Thank you for elaborating.<br>
When you are talking about compression, is this related to debug info coming in compressed already, or something else?<br></div></div></blockquote><div><br>Both/either compressed input (which if I remember correctly gets fully decompressed into a buffer and that buffer may be kept alive for most/all of the llvm-dwp run - I don't remember exactly how that goes) and compressed output (which first llvm-dwp passes bytes to MCStreamer, which buffers every section itself, then it has to write that section contents into a compressed buffer which also stays alive until it's written out to the output file, etc).<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
Regarding MCStremer what would be the alternative? In Bolt it provides a nice level of abstraction for us as we output new updated binary, and write out dwo files, in debug fission case.</div></div></blockquote><div><br>Some kind of lighter weight abstraction (or refactoring of MCStreamer to make or allow it to be lighter weight in some/many cases - eg: if a user knows the important facts (size, etc) that are needed to emit headers, layout the object, etc then get a callback to emit the section's bytes when needed - so if they're parametrically computed (eg: a function of some input file, bytes from a StringMap, etc) or simply mapped from some input file, then those bytes can be emitted without MCStreamer to ever have to take ownership of the byte buffer/make its own).<br><br>Personally I'd love it if the abstraction was lightweight enough to be shared with lld and orc (well, I guess orc probably already uses MCStreamer, but perhaps it can benefit from these reductions in overhead).<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">In general, the usage model for BOLT is in some ways similar to llvm-dwp, except we don't really deal with compressed debug information. Some sections are pass through, but others get either modified, .debug_info, or complete re-written, .debug_loc. As an example.
 For llvm-dwp the .debug-str-offset and .debug-str section gets re-written. Although much more data is modified/replaced before being written out in bolt case. So, I am not sure pure in/out performance is as critical for us at the moment. <br></div></div></blockquote><div><br>Fair enough.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">I took initial step of factoring out llvm-dwp code in to it's own library. To see what it will look like. What I ended up is with few APIs that take in MCStreamer, and all the code for dealing with it is in main function of llvm-dwp.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
With all of this said, and Bolt usage model, I think dealing with MCStreamer issue can be deferred to after refactoring to library/adding functionality to BOLT.<br>
<br>
Alex</div>
<div id="gmail-m_-3235380410558138849appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-3235380410558138849divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>><br>
<b>Sent:</b> Monday, June 21, 2021 6:41 PM<br>
<b>To:</b> Alexander Yermolovich <<a href="mailto:ayermolo@fb.com" target="_blank">ayermolo@fb.com</a>><br>
<b>Cc:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; Maksim Panchenko <<a href="mailto:maks@fb.com" target="_blank">maks@fb.com</a>><br>
<b>Subject:</b> Re: [RFC] Refactor llvm-dwp in to a library.</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr">On Mon, Jun 21, 2021 at 6:28 PM Alexander Yermolovich <<a href="mailto:ayermolo@fb.com" target="_blank">ayermolo@fb.com</a>> wrote:<br>
</div>
<div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
Hello David<br>
<br>
I haven't dug into llvm-dwp performance. What are some of the performance pain points that you know about?<br>
</div>
</div>
</blockquote>
<div><br>
Yeah - using LLVM's higher level abstractions for writing object files (MCStreamer et, al) means that, as far as I recall, all the output ends up buffered in memory before being written out - whereas, ideally, it'd be streamed (memcpy to/from memory mapped
 files) from input file to output file (potentially through streamed compression/decompression where possible too - another layer of the MCStreamer abstractions that can add cost (though I don't think I implemented support for compressing output in llvm-dwp,
 though it'd be trivial to add because it's already supported in MCStreamer (but that support does buffer the whole uncompressed and compressed data... ))). Maybe some other things, but that's certainly the top of my list.<br>
<br>
- Dave<br>
 </div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
Thank You<br>
Alex</div>
<div id="gmail-m_-3235380410558138849x_gmail-m_-8798475053668546221appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-3235380410558138849x_gmail-m_-8798475053668546221divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Alexander Yermolovich<br>
<b>Sent:</b> Monday, June 21, 2021 6:11 PM<br>
<b>To:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Cc:</b> <a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a> <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>>; Maksim Panchenko <<a href="mailto:maks@fb.com" target="_blank">maks@fb.com</a>><br>
<b>Subject:</b> [RFC] Refactor llvm-dwp in to a library.</font>
<div> </div>
</div>
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
Hello<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
I am working on adding support for bolt (<a href="https://github.com/facebookincubator/BOLT/tree/rebased" id="gmail-m_-3235380410558138849x_gmail-m_-8798475053668546221LPlnk635887" target="_blank">https://github.com/facebookincubator/BOLT/tree/rebased</a>) to write out DWP directly. 
 I want to re-use as much llvm-dwp functionality as possible. <br>
Plan is to move most of functionality that is now in llvm-dwp in to llvm/lib/DWP, with corresponding header file in llvm/include/llvm/DWP.<br>
In the header files have<br>
getContributionIndex<br>
handleSection<br>
parseCompileUnitHeader<br>
writeStringsAndOffsets<br>
getCUIdentifiers<br>
buildDuplicateError<br>
writeIndex<br>
<br>
<span style="background-color:rgb(255,255,255)">For structs that are passed around define in the header also.</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<div style="color:rgb(212,212,212);background-color:rgb(30,30,30);font-family:Menlo,Monaco,"Courier New",monospace;font-weight:normal;font-size:12px;line-height:18px">
<span><span style="color:rgb(78,201,176);background-color:rgb(255,255,255)">UnitIndexEntry</span></span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<div style="color:rgb(212,212,212);background-color:rgb(30,30,30);font-family:Menlo,Monaco,"Courier New",monospace;font-weight:normal;font-size:12px;line-height:18px">
<span><span style="color:rgb(78,201,176);background-color:rgb(255,255,255)">CompileUnitHeader</span></span></div>
<div style="color:rgb(212,212,212);background-color:rgb(30,30,30);font-family:Menlo,Monaco,"Courier New",monospace;font-weight:normal;font-size:12px;line-height:18px">
<span><span style="color:rgb(78,201,176);background-color:rgb(255,255,255)">CompileUnitIdentifiers</span></span></div>
<br>
</div>
<br>
Thought I would solicit opinions before I dive too deep into this. <br>
<br>
Thank You<br>
Alex</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>

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