<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 29, 2016 at 3:36 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">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 MCEncodedFragmentWithFixups::Fixups<br>
and the arguments could be directly moved into the fields of a newly created<br>
MCDataFragment.<br>
<br>
Would that work for your use case?<br></blockquote><div><br></div><div>Not quite, unfortunately - the issue is that we're doing a task that is essentially "linking + a bit" - so imagine linking a bunch of files together, the final, say, debug_info.dwo section is made up of the concatenation of all the debug_info.dwo sections of the inputs. So it's fragmented and it's already available, memory mapped, never in a SmallVector, etc.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Peter<br>
<div><div class="h5"><br>
On Mon, Feb 29, 2016 at 03:18:22PM -0800, David Blaikie via llvm-dev wrote:<br>
> Just in case it interests anyone else, I'm playing around with trying to<br>
> broaden the MCStreamer API to allow for emission of bytes without copying<br>
> the contents into a local buffer first (either because you already have a<br>
> buffer, or the bytes are already present in another file, etc) in<br>
> <a href="http://reviews.llvm.org/D17694" rel="noreferrer" target="_blank">http://reviews.llvm.org/D17694</a> . In theory there's some overlap with lld<br>
> here (no doubt it already does this sort of thing, but not in a way, I<br>
> assume, we could reuse from other tools at the moment) and my motivation,<br>
> llvm-dwp, looks very much like "linking with a few extra steps".<br>
><br>
> But to check that these changes might be more generally applicable, I<br>
> thought I'd solicit data from anyone building tools that might be memory<br>
> constrained as well.<br>
><br>
> First that comes to mind (Eric suggested/mentioned) is llvm-dsymutil.<br>
><br>
> Adrian/Fred - do you guys ever have trouble with memory usage of<br>
> llvm-dsymutil? Do you have an example you could provide that has high<br>
> memory usage, so I could see if any simple changes based on my prototype MC<br>
> changes would help.<br>
><br>
> A quick glance at dsymutil's code indicates it might benefit slightly, at<br>
> least - in the string table emission, for example (it looks very similar to<br>
> string table emission in dwp - just being able to reference the strings in<br>
> the StringMap rather than copying them into MCStreamer could help (also I<br>
> found using a DenseMap<StringRef to the memory mapped input helped as well<br>
> - but that's a change you can make locally without any MCStreamer<br>
> improvements) - other parts might be trickier, and consist of parts of<br>
> referencable data (like the line table header)  and parts that are not<br>
> referencable (like their contents) - my prototype could be extended to<br>
> handle that)<br>
<br>
</div></div>> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Peter<br>
</font></span></blockquote></div><br></div></div>