aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CodeGenModule.cpp
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 /clang/lib/CodeGen/CodeGenModule.cpp
parent6648a0817ef664d75374b303c1f4abb350576f31 (diff)
downloadllvm-456c9968e51cc015f803cca1063703fbbc6fe958.zip
llvm-456c9968e51cc015f803cca1063703fbbc6fe958.tar.gz
llvm-456c9968e51cc015f803cca1063703fbbc6fe958.tar.bz2
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 'clang/lib/CodeGen/CodeGenModule.cpp')
0 files changed, 0 insertions, 0 deletions