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

[Duncan Exon Smith via llvm-commits]

On Mar 28, 2016, at 4:24 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

>> +const uint8_t *StreamingMemoryObject::getPointer(uint64_t Address,
>> +                                                 uint64_t Size) const {
>> +  fetchToPos(Address + Size - 1);
>> +  return &Bytes[Address + BytesSkipped];
>> +}
>> +
> 
> BTW, any thoughts about using a std::vector<std::pair<unsigned,
> uint8_t*>> Bytes in StreamingMemoryObject?
> 
> The idea is that each read advances the file from Pos and reads it
> into a new buffer whose offset and pointer is added to Bytes. The
> restriction to using getPointer then is just that the entire blob be
> fetched in one read, but the returned pointers would always be valid.
> 

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. 

Worth it if/when we have a compelling use case for keeping blobs alive but probably not until then IMO. 

There's also a question of whether MemoryObject has (or should have) more clients than BitsreamReader.  What if a client calls getPointer with overlapping ranges?   The first one reshuffles the vector, and we can return the pointer.  But then the second one invalidates the first.  (Hypothetical though.)

> Cheers,
> Rafael