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

Duncan P. N. Exon Smith via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 28 07:49:05 PDT 2016


> 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?

> 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.


More information about the llvm-commits mailing list