summaryrefslogtreecommitdiffstats
path: root/llvm/test/Bitcode/2009-06-11-FirstClassAggregateConstant.ll
diff options
context:
space:
mode:
authorDuncan P. N. Exon Smith <dexonsmith@apple.com>2016-03-27 23:00:59 +0000
committerDuncan P. N. Exon Smith <dexonsmith@apple.com>2016-03-27 23:00:59 +0000
commit456c9968e51cc015f803cca1063703fbbc6fe958 (patch)
treee3784174127e00deb1f71b70b3503e70047f2ff6 /llvm/test/Bitcode/2009-06-11-FirstClassAggregateConstant.ll
parent6648a0817ef664d75374b303c1f4abb350576f31 (diff)
downloadbcm5719-llvm-456c9968e51cc015f803cca1063703fbbc6fe958.tar.gz
bcm5719-llvm-456c9968e51cc015f803cca1063703fbbc6fe958.zip
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. llvm-svn: 264549
Diffstat (limited to 'llvm/test/Bitcode/2009-06-11-FirstClassAggregateConstant.ll')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud