Thanks. hopefully someone will soon.<div><br></div><div>I need to add one amendment to the above description:</div><div>Since the container for bitcode doesn't really act all that much like a vector, I renamed it to BitstreamBytes, and the way to get the bitcode bytes is just a getByte/getWord method rather than operator[]. Otherwise the description still applies.</div>
<div><br></div><div><br></div><div><br><div class="gmail_quote">On Tue, Nov 15, 2011 at 12:41 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Nov 14, 2011 at 10:54 AM, Derek Schuff <<a href="mailto:dschuff@google.com">dschuff@google.com</a>> wrote:<br>
> Ping?<br>
> Could someone take a look at this? (or, have I sent it to the wrong<br>
> place/not marked it properly?)<br>
<br>
</div>This is the right place; not sure why nobody has responded.<br>
<br>
-Eli<br>
<div><div class="h5"><br>
> On Wed, Nov 9, 2011 at 4:57 PM, Derek Schuff <<a href="mailto:dschuff@google.com">dschuff@google.com</a>> wrote:<br>
>><br>
>> Hello all,<br>
>> The following is a proposal (and a prototype patch) to enable bitcode<br>
>> streaming. The overall goal is to be able to overlap bitcode<br>
>> reading/download with compilation, a functionality useful obviously for<br>
>> pnacl and renderscript but also potentially for any situation where the<br>
>> interface between the frontend and backend is something other than a file.<br>
>> In the current state of the world, at a high level, there are 2 things<br>
>> keeping this from happening. The first is that BitcodeReader construction<br>
>> takes a MemoryBuffer which it expects to be filled with bitcode, and inside<br>
>> BitcodeReader, the BitstreamCursor (which is the primary interface to the<br>
>> bitcode itself) gets pointers to the bitcode in memory, and does all of its<br>
>> magic with pointer arithmetic. The second issue is that in<br>
>> BitcodeReader::ParseModule (which is run when right after the Module and<br>
>> BitcodeReader objects are created), the reader makes a pass over the entire<br>
>> bitcode file. This step does everything except read the function bodies, but<br>
>> it records the bit locations of each function for future materialization.<br>
>> High-level change description:<br>
>> This patch creates a class called BitcodeStream, which is a very simple<br>
>> interface with one method (GetBytes), which fetches the requested number of<br>
>> bytes from the stream, and writes them into the requested destination. This<br>
>> method may block the calling thread if there are not yet enough bytes<br>
>> available in the stream buffer (similarly to a stdin or socket read).<br>
>> The first issue above is addressed by introducing the BitstreamVector, an<br>
>> abstraction that wraps the bitcode in memory. Instead of using pointers, the<br>
>> BitstreamCursor uses indices and gets bitcode bytes by indexing (i.e.<br>
>> operator[] ) the BitstreamVector. When streaming is not used, the<br>
>> BitstreamVector itself keeps pointers to the start and end of the backing<br>
>> MemoryBuffer and the indexing operator is just a pointer dereference. For<br>
>> streaming use, the BitstreamVector has a BitcodeStream object. If a byte is<br>
>> requested that has not yet been fetched, it calls GetBytes to get more,<br>
>> until it has enough to return the requested byte.<br>
>> This model of allowing any byte to be requested and blocking the caller<br>
>> has the advantage that there is no structural/architectural change required<br>
>> at this lowest level, nor at the high level (A FunctionPassManager is used<br>
>> to iterate over all the functions and compile each one).<br>
>> The second issue is solved by 2 simple changes. The first is in<br>
>> ParseModule. Instead of a single pass over all the bitcode, ParseModule<br>
>> becomes resumable.  ParseModule will do its normal handling for top-level<br>
>> records, type table blocks, metadata, etc, but if streaming is in use, it<br>
>> will save its state and return as soon as a function subblock is encountered<br>
>> (rather than saving its location and skipping over it). Each subsequent time<br>
>> it is called, it bookmarks and skips one function block. Later, when a<br>
>> function needs to be materialized, if the function body has been seen<br>
>> already, then materialization is the same as before. Otherwise, Materialize<br>
>> will keep calling ParseModule (each time bookmarking and skipping one<br>
>> function body) until the requested function is found. The one other change<br>
>> required to make this work simply is that the bitcode writer writes function<br>
>> bodies as the last subblock (currently the attachment metadata and value<br>
>> symbol table are written after the function bodies).<br>
>> The prototype patch is attached and can also be viewed online at<br>
>> <a href="http://codereview.chromium.org/8393017/" target="_blank">http://codereview.chromium.org/8393017/</a> . Feedback is welcome, as well as<br>
>> guidance from the relevant code owners/reviewers regarding what the next<br>
>> step needs to be toward committing this.<br>
>> Thanks,<br>
>> -Derek<br>
><br>
</div></div>> _______________________________________________<br>
> llvm-commits mailing list<br>
> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
><br>
><br>
</blockquote></div><br></div>