[llvm] r264549 - Support: Implement StreamingMemoryObject::getPointer

[Rafael Espíndola via llvm-commits]

On 28 March 2016 at 10:49, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>
>> On 2016-Mar-28, at 07:05, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>>
>>> The way bitcode gets read in practice could make that a little complicated.  If there's a blob inside a function and we skip past it (without knowing it's a blob) then it could end up in multiple allocations.  When someone comes back and calls getPointer then StreamingMemoryObject would have to split it up after the fact and insert into (e.g.) near the beginning of that vector.
>>
>> The skip would still be a read from the point of view of
>> StreamingMemoryObject, so the entire function with the blob in it
>> would be in a single buffer/entry in the vector.
>
> Does that imply that the StreamingMemoryObject wouldn't fetch ahead
> CHUNK_SIZE bytes at a time?  Or would this vector<int, char*> be a
> second layer of buffering?

Correct. It would always fetch until the requested position. The
caller just has to make sure that it never splits a blob in multiple
reads.


>> I think with that we should be able to clean the BitstreamReader to
>> always take a MemoryObject instead of having two modes.
>
> I think this is already true.  The constructor that takes an array of
> bytes is just convenience.  It creates a non-streaming memory object.

True. This is much nicer now than I remembered.

Cheers,
Rafael