<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 29, 2016 at 5:12 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Feb 29, 2016 at 03:47:49PM -0800, David Blaikie wrote:<br>
> On Mon, Feb 29, 2016 at 3:36 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>><br>
> wrote:<br>
><br>
> > Hi David,<br>
> ><br>
> > The way I imagined that we might want to extend the MCStreamer API (this<br>
> > was motivated by DIEData) is by allowing clients to move bytes and fixups<br>
> > into the MC layer.<br>
> ><br>
> > This is the sort of API that I was imagining:<br>
> ><br>
> > void MoveAndEmitFragment(SmallVectorImpl<char> &&Data,<br>
> >                          SmallVectorImpl<MCFixup> &&Fixups);<br>
> ><br>
> > Note that this mirrors the fields<br>
> > MCEncodedFragmentWithContents::Contents and<br>
> > MCEncodedFragmentWithFixups::Fixups<br>
> > and the arguments could be directly moved into the fields of a newly<br>
> > created<br>
> > MCDataFragment.<br>
> ><br>
> > Would that work for your use case?<br>
> ><br>
><br>
> Not quite, unfortunately - the issue is that we're doing a task that is<br>
> essentially "linking + a bit" - so imagine linking a bunch of files<br>
> together, the final, say, debug_info.dwo section is made up of the<br>
> concatenation of all the debug_info.dwo sections of the inputs. So it's<br>
> fragmented and it's already available, memory mapped, never in a<br>
> SmallVector, etc.<br>
<br>
</span>I see. I guess there's a couple of ways you can go with llvm-dwp:<br>
1) Extend MC with optional ownership as you are doing in your patch.<br>
2) Modify llvm-dwp to write object files directly.<br>
<br>
2 is what lld does (with the help of libObject) and might not be such a bad<br>
choice, but it would be adding a lot of machinery for a very specific task<br>
that MC already needs to know how to do in a roughly target-independent way,<br>
so maybe it would be overkill.<br></blockquote><div><br></div><div>Yeah, if lld's code for doing this were more reusable that might be an option, but I assume it isn't. (alternatively, could move dwp tool to be a subproject of lld itself, a "dwp" driver that would just enable the special treatment of cu/tu_index sections) At least for my needs, the modifications to MC seem sufficiently unobtrusive & potentially generally useful (eventually LLVM might care about the memory impact of MC - perhaps for especially weird inputs (large amounts of static data, for example)).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I reckon that in most cases MC clients aren't going to be copying large<br>
amounts of unowned data, they're most likely going to be creating that<br>
data. So perhaps the implementation should reflect that somehow.<br></blockquote><div><br></div><div>Yeah, even for that, though - they may not want to keep it all in memory. For example one of the next largest memory costs in dwp is the str_offsets section, where we emit a bunch of ints created by processing the input. I know how big the output will be, but I don't want/need to allocate a vector of all of them, if I could stream them out instead.<br><br>So in theory we could generalize more aggressively, rather than narrow down the usage - if I could pass a thing that could be queried for size and could write bytes to the underlying entity I could save that memory too. So could LLVM - for example, type units wouldn't need to all be stored in bytes before writing any part of them out, we could stream it out to disk. (there's some buffering in Clang that adds another layer to get through - so it's actually buffered twice, the MC changes only remove one layer, we'd have to change clang (& change MC to not require pwrite to patch the header) to avoid the buffering entirely)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Specifically what I had in mind was that you could add some other derived class<br>
of MCFragment that would store a StringRef (or maybe a vector of StringRefs<br>
if that proves useful), and that would be unrelated to MCDataFragment.<br></blockquote><div><br></div><div>(needs multiple StringRefs - the output section consists of the concatenation of all the input sections - so in the simple case it's a StringRef from each input)<br><br>But yeah, could possibly narrow down the usage. I haven't looked closely at how the MCFragments are created/used/manipulated (some of this conversation may be better placed in the Differential review thread, perhaps - I do really appreciate your perspective)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
WDYT?<br>
<br>
Thanks,<br>
<span class="HOEnZb"><font color="#888888">--<br>
Peter<br>
</font></span></blockquote></div><br></div></div>