| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
These interfaces are no longer used.
Differential Revision: https://reviews.llvm.org/D26222
llvm-svn: 285774
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
This reverts commit r264409 since it failed to bootstrap:
http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/8302/
llvm-svn: 264410
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Optimize output of MDStrings in bitcode. This emits them in big blocks
(currently 1024) in a pair of records:
- BULK_STRING_SIZES: the sizes of the strings in the block, and
- BULK_STRING_DATA: a single blob, which is the concatenation of all
the strings.
Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this
should (a) slightly reduce bitcode size, since there is less record
overhead, and (b) greatly improve reading speed, since blobs are super
cheap to deserialize.
I needed to add support for blobs to streaming input to get the test
suite passing.
- StreamingMemoryObject::getPointer reads ahead and returns the
address of the blob.
- To avoid a possible reallocation of StreamingMemoryObject::Bytes,
BitstreamCursor::readRecord needs to move the call to JumpToEnd
forward so that getPointer is the last bitstream operation.
llvm-svn: 264409
|
| |
|
|
|
|
| |
Apparently, the style needs to be agreed upon first.
llvm-svn: 240390
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using this command:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
llvm/lib/
Thanks to Eugene Kosov for the original patch!
llvm-svn: 240137
|
| |
|
|
|
|
| |
We were already deleting it, this just makes it explicit.
llvm-svn: 239867
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The existing code for method StreamingMemoryObject.fetchToPos does not respect
the corresonding call to setKnownObjectSize(). As a result, it allows the
StreamingMemoryObject to read bytes past the object size.
This patch provides a test case, and code to fix the problem.
Patch by Karl Schimpf
Differential Revision: http://reviews.llvm.org/D8931
llvm-svn: 237939
|
| |
|
|
|
|
| |
NFC.
llvm-svn: 232976
|
| |
|
|
|
|
| |
requiring the macro. NFC; LLVM edition.
llvm-svn: 229340
|
| |
|
|
|
|
| |
evaluate to true). Also fixing a -Wcast-qual warning, where the cast expression isn't required.
llvm-svn: 221888
|
| |
|
|
|
|
|
| |
The reading of 64 bit values could still be optimized, but at least this cuts
down on the number of virtual calls to fetch more data.
llvm-svn: 221865
|
| |
|
|
|
|
|
| |
This allows the removal of isObjectEnd and opens the way for reading 64 bits
at a time.
llvm-svn: 221804
|
| |
|
|
|
|
|
| |
Returning more information will allow BitstreamReader to be simplified a bit
and changed to read 64 bits at a time.
llvm-svn: 221794
|
|
|
Every MemoryObject is a StreamableMemoryObject since the removal of
StringRefMemoryObject, so just merge the two.
I will clean up the MemoryObject interface in the upcoming commits.
llvm-svn: 221766
|
