diff options
| author | Duncan P. N. Exon Smith <dexonsmith@apple.com> | 2016-03-27 23:00:59 +0000 |
|---|---|---|
| committer | Duncan P. N. Exon Smith <dexonsmith@apple.com> | 2016-03-27 23:00:59 +0000 |
| commit | fbf768a4d3b4480c140cebbf882aadd499b32c28 (patch) | |
| tree | d0d0b06be2a3fe3cb32c108af7669e7440333310 /test/Bitcode/Inputs | |
| parent | b341866e2c865b56f36fa7d55a8c22d0101bd99a (diff) | |
Support: Implement StreamingMemoryObject::getPointer
The implementation is fairly obvious. This is preparation for using
some blobs in bitcode.
For clarity (and perhaps future-proofing?), I moved the call to
JumpToBit in BitstreamCursor::readRecord ahead of calling
MemoryObject::getPointer, since JumpToBit can theoretically (a) read
bytes, which (b) invalidates the blob pointer.
This isn't strictly necessary the two memory objects we have:
- The return of RawMemoryObject::getPointer is valid until the memory
object is destroyed.
- StreamingMemoryObject::getPointer is valid until the next chunk is
read from the stream. Since the JumpToBit call is only going ahead
to a word boundary, we'll never load another chunk.
However, reordering makes it clear by inspection that the blob returned
by BitstreamCursor::readRecord will be valid.
I added some tests for StreamingMemoryObject::getPointer and
BitstreamCursor::readRecord.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264549 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'test/Bitcode/Inputs')
| -rw-r--r-- | test/Bitcode/Inputs/invalid-fixme-streaming-blob.bc | bin | 371 -> 0 bytes |
1 files changed, 0 insertions, 0 deletions
diff --git a/test/Bitcode/Inputs/invalid-fixme-streaming-blob.bc b/test/Bitcode/Inputs/invalid-fixme-streaming-blob.bc Binary files differdeleted file mode 100644 index 7e32f8b0774..00000000000 --- a/test/Bitcode/Inputs/invalid-fixme-streaming-blob.bc +++ /dev/null |