18 Commits

Author SHA1 Message Date
Rafael Espindola
21641494c7 Make a few helper functions static. NFC.
llvm-svn: 221930
2014-11-13 21:54:59 +00:00
Rafael Espindola
38fb6912e0 Factor out call to push_back. NFC.
llvm-svn: 221490
2014-11-06 22:39:16 +00:00
Benjamin Kramer
0157ffa1ec Use IntrusiveRefCntPtr to manage the lifetime of BitCodeAbbrevs.
This doesn't change the interface or gives additional safety but removes
a ton of retain/release boilerplate.

No functionality change.

llvm-svn: 217778
2014-09-15 15:44:14 +00:00
Craig Topper
701fca8e8d Replace some assert(0)'s with llvm_unreachable.
llvm-svn: 211141
2014-06-18 05:05:13 +00:00
Craig Topper
c2260fc0ab [C++11] More 'nullptr' conversion. In some cases just using a boolean check instead of comparing to nullptr.
llvm-svn: 206252
2014-04-15 06:32:26 +00:00
Jordan Rose
efb09ff4dc Micro-optimization: don't shift an entire bitcode record over to get the code.
Previously, BitstreamCursor read an abbreviated record by splatting the
whole thing into a data vector, then extracting and removing the /first/
element. Now, it reads the first element--the record code--separately from
the actual field values.

No (intended) functionality change.

llvm-svn: 181639
2013-05-10 22:17:10 +00:00
Joe Abbey
f809052035 Whitespace cleanup
llvm-svn: 178454
2013-04-01 02:28:07 +00:00
Jakub Staszak
54c2a5fb77 Simplify code. No functionality change.
llvm-svn: 175501
2013-02-19 09:48:30 +00:00
Chris Lattner
247a573f43 Fix the underlying problem that was causing read(0) to be called: sometimes the
bitcode writer would generate abbrev records saying that the abbrev should be
filled with fixed zero-bit bitfields (this happens in the .bc writer when 
the number of types used in a module is exactly one, since log2(1) == 0).

In this case, just handle it as a literal zero.  We can't "just fix" the writer
without breaking compatibility with existing bc files, so have the abbrev reader
do the substitution.

Strengthen the assert in read to reject reads of zero bits so we catch such 
crimes in the future, and remove the special case designed to handle this.

llvm-svn: 174801
2013-02-09 07:07:29 +00:00
Joe Abbey
6de61a11af Code Custodian (trivial whitespace cleanup)
llvm-svn: 174550
2013-02-06 22:14:06 +00:00
Chris Lattner
30c0e49a51 Fix a heinous inefficiency introduced in r149918, wherein reading each byte of a
BLOB (i.e., large, performance intensive data) in a bitcode file was switched to
invoking one virtual method call per byte read.  Now we do one virtual call per
BLOB.

llvm-svn: 173065
2013-01-21 18:24:49 +00:00
Chris Lattner
4597032edd wean Blob handling logic off of banging on NextChar directly. Instead, make
it reason about the current bit position, which is always independent of the
underlying cursors word size.

llvm-svn: 173063
2013-01-21 18:18:25 +00:00
Chris Lattner
81975ff989 rename "SkipToWord" to "SkipToFourByteBoundary" since a word is not always 4 bytes.
llvm-svn: 173062
2013-01-21 18:04:19 +00:00
Chris Lattner
56672a0fc8 convert the bitstream reader itself and the IR .bc file parser to use the new advance() APIs,
simplifying things and making a bunch of details more private to BitstreamCursor.

llvm-svn: 172947
2013-01-20 02:13:19 +00:00
Chris Lattner
2d0eb94aea stringref'ize readRecord and properly capitalize it. Add a compatibility method to easy
the transition.

llvm-svn: 172940
2013-01-20 01:06:48 +00:00
Chris Lattner
9ae8e75d23 move some private methods out of line, add a skipRecord() method.
llvm-svn: 172931
2013-01-20 00:00:00 +00:00
Chris Lattner
4589d285da Add a new BitstreamEntry concept, and add two helper methods for walking
through a BitstreamCursor that produce it: advance() and 
advanceSkippingSubblocks(), representing the two most common ways clients
want to walk through bitcode.

llvm-svn: 172919
2013-01-19 21:35:24 +00:00
Chris Lattner
1eaf2fb33a BitstreamReader hasn't aged well. It's been hacked on by various people and
has past the point of making sense.  Lets tidy things up: first step, moving
a ton of big functions out of line.

llvm-svn: 172904
2013-01-19 18:19:39 +00:00