<div dir="ltr">Agreed that we should consider removing it, but I'd like to first make sure this is ok with the PNaCl developers. I'll send an RFC to llvm-dev.<div><br></div><div>Separately though this patch would seem to be a useful step towards removing it due to the switch to a mostly buffer-based interface.</div><div><br></div><div>Peter</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 28, 2016 at 6:00 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Can we just delete it and the streaming reader?<br>
<br>
My understanding was that it was just used for PNaCl and PNaCl is<br>
moving to subzero.<br>
<br>
Cheers,<br>
Rafael<br>
<br>
<br>
On 28 October 2016 at 05:14, Peter Collingbourne via llvm-commits<br>
<div><div class="h5"><<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
> pcc created this revision.<br>
> pcc added a reviewer: mehdi_amini.<br>
> pcc added a subscriber: llvm-commits.<br>
><br>
> This simplifies the existing MemoryObject interface to the following:<br>
><br>
> /// Returns a reference to a buffer containing all of the data read so far.<br>
> ArrayRef<uint8_t> getBuffer() const;<br>
><br>
> /// Try to extend the buffer held by this MemoryObject to at least Size<br>
> /// bytes. Calling this function invalidates any buffer previously<br>
> /// returned by getBuffer().<br>
> ///<br>
> /// @result True if successful.<br>
> bool tryExtendTo(uint64_t Size);<br>
><br>
> /// Returns the size of the region in bytes.  (The region is contiguous, so<br>
> /// the highest valid address of the region is getExtent() - 1). Calling this<br>
> /// function invalidates any buffer previously returned by getBuffer().<br>
> ///<br>
> /// @result The size of the region.<br>
> uint64_t getExtent();<br>
><br>
> This interface is not only smaller, but it results in better performance<br>
> likely as a result of avoiding a virtual call and a copy for each word we<br>
> read. I observed a performance improvement of 7.5% when using "llvm-dis<br>
> -disable-output" and 3% when using "opt -disable-output -disable-verify"<br>
> to read a bitcode file of size ~11MB (median of 100 runs).<br>
><br>
><br>
> <a href="https://reviews.llvm.org/D26068" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D26068</a><br>
><br>
> Files:<br>
>   llvm/include/llvm/Bitcode/<wbr>BitstreamReader.h<br>
>   llvm/include/llvm/Support/<wbr>MemoryObject.h<br>
>   llvm/include/llvm/Support/<wbr>StreamingMemoryObject.h<br>
>   llvm/lib/Bitcode/Reader/<wbr>BitcodeReader.cpp<br>
>   llvm/lib/Support/<wbr>StreamingMemoryObject.cpp<br>
>   llvm/unittests/Support/<wbr>StreamingMemoryObjectTest.cpp<br>
><br>
><br>
</div></div>> ______________________________<wbr>_________________<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/<wbr>mailman/listinfo/llvm-commits</a><br>
><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div>