13 Commits

Author SHA1 Message Date
David Blaikie
0581f9f375 Reapply "Make BitCodeAbbrev ownership explicit using shared_ptr rather than IntrusiveRefCntPtr""
If this is a problem for anyone (shared_ptr is two pointers in size,
whereas IntrusiveRefCntPtr is 1 - and the ref count control block that
make_shared adds is probably larger than the one int in RefCountedBase)
I'd prefer to address this by adding a lower-overhead version of
shared_ptr (possibly refactoring IntrusiveRefCntPtr into such a thing)
to avoid the intrusiveness - this allows memory ownership to remain
orthogonal to types and at least to me, seems to make code easier to
understand (since no implicit ownership acquisition can happen).

This recommits 291006, reverted in r291007.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291016 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-04 22:36:33 +00:00
David Blaikie
23e393fa4d Revert "Make BitCodeAbbrev ownership explicit using shared_ptr rather than IntrusiveRefCntPtr"
Breaks Clang's use of bitcode. Reverting until I have a fix to go with
it there.

This reverts commit r291006.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291007 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-04 21:19:28 +00:00
David Blaikie
fe94ca2934 Make BitCodeAbbrev ownership explicit using shared_ptr rather than IntrusiveRefCntPtr
If this is a problem for anyone (shared_ptr is two pointers in size,
whereas IntrusiveRefCntPtr is 1 - and the ref count control block that
make_shared adds is probably larger than the one int in RefCountedBase)
I'd prefer to address this by adding a lower-overhead version of
shared_ptr (possibly refactoring IntrusiveRefCntPtr into such a thing)
to avoid the intrusiveness - this allows memory ownership to remain
orthogonal to types and at least to me, seems to make code easier to
understand (since no implicit ownership acquisition can happen).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291006 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-04 21:13:35 +00:00
Peter Collingbourne
8fc9b4d314 Bitcode: Decouple block info block state from reader.
As proposed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/106630.html

Move block info block state to a new class, BitstreamBlockInfo.
Clients may set the block info for a particular cursor with the
BitstreamCursor::setBlockInfo() method.

At this point BitstreamReader is not much more than a container for an
ArrayRef<uint8_t>, so remove it and replace all uses with direct uses
of memory buffers.

Differential Revision: https://reviews.llvm.org/D26259

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286207 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-08 04:17:11 +00:00
Peter Collingbourne
7cfe6227d3 Bitcode: Fix short read implementation.
We need to zero extend the byte in order to correctly shift it into a
64-bit value.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285785 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-02 02:58:47 +00:00
Peter Collingbourne
e8516587a2 Bitcode: Change reader interface to take memory buffers.
As proposed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/106595.html

This change also fixes an API oddity where BitstreamCursor::Read() would
return zero for the first read past the end of the bitstream, but would
report_fatal_error for subsequent reads. Now we always report_fatal_error
for all reads past the end. Updated clients to check for the end of the
bitstream before reading from it.

I also needed to add padding to the invalid bitcode tests in
test/Bitcode/. This is because the streaming interface was not checking that
the file size is a multiple of 4.

Differential Revision: https://reviews.llvm.org/D26219

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285773 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-02 00:08:19 +00:00
Duncan P. N. Exon Smith
75f9dc9b05 Explicitly test BitstreamReader::setArtificialByteLimit, NFC
Explicitly check that artificial byte limit is rounded correctly by
exposing BitstreamReader::Size through a new accessor, getSizeIfKnown.

The original code for rounding (from r264547) wasn't obviously correct,
and even though r264623 cleaned it up (by calling llvm::alignTo) I think
it's worth testing.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264650 91177308-0d34-0410-b5e6-96231b3b80d8
2016-03-28 20:39:41 +00:00
Duncan P. N. Exon Smith
2686d302c0 Remove accidentally duplicated test
This was identical to setArtificialByteLimitNotWordBoundary.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264646 91177308-0d34-0410-b5e6-96231b3b80d8
2016-03-28 20:30:15 +00:00
Duncan P. N. Exon Smith
bd2e7848ab Bitcode: Fix MSVC bot failure from r264549
make_unique => llvm::make_unique

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264553 91177308-0d34-0410-b5e6-96231b3b80d8
2016-03-27 23:36:55 +00:00
Duncan P. N. Exon Smith
fbf768a4d3 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
2016-03-27 23:00:59 +00:00
Duncan P. N. Exon Smith
a115062beb Bitcode: Add SimpleBitstreamCursor::setArtificialByteLimit
Allow users of SimpleBitstreamCursor to limit the number of bytes
available to the cursor.  This is preparation for instantiating a cursor
that isn't allowed to load more bytes from a StreamingMemoryObject (just
move around the ones already-loaded).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264547 91177308-0d34-0410-b5e6-96231b3b80d8
2016-03-27 22:49:32 +00:00
Duncan P. N. Exon Smith
2e87e9ef90 Bitcode: Add SimpleBitstreamCursor::getPointerToByte, etc.
Add API to SimpleBitstreamCursor to allow users to translate between
byte addresses and pointers.

  - jumpToPointer: move the bit position to a particular pointer.
  - getPointerToByte: get the pointer for a particular byte.
  - getPointerToBit: get the pointer for the byte of the current bit.
  - getCurrentByteNo: convenience function for assertions and tests.

Mainly adds unit tests (getPointerToBit/Byte already has a use), but
also preparation for eventually using jumpToPointer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264546 91177308-0d34-0410-b5e6-96231b3b80d8
2016-03-27 22:45:25 +00:00
Jordan Rose
2217648f91 [Bitcode] AtEndOfStream should only check against the size if it's known.
This avoids an issue where AtEndOfStream mistakenly returns true at the /start/ of
a stream.

(In the rare case that the size is known and actually 0, the slow path will still
handle it correctly.)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221840 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-13 00:08:41 +00:00