| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
The bitcode writer emits a reference to the attribute group that the object at
the given index refers to. The bitcode reader is modified to read this in and
map it back to the attribute group.
llvm-svn: 174952
|
|
|
|
| |
llvm-svn: 174950
|
|
|
|
| |
llvm-svn: 174911
|
|
|
|
| |
llvm-svn: 174910
|
|
|
|
| |
llvm-svn: 174864
|
|
|
|
|
|
|
|
| |
I have some uncommitted changes to the cast code that catch this sort of thing
at compile-time but I still need to do some other cleanup before I can enable
it.
llvm-svn: 174853
|
|
|
|
|
|
|
|
|
| |
This reads the attribute groups. It currently doesn't do anything with them.
NOTE: In the commit to the bitcode writer, the format *may* change in the near
future. Which means that this code would also change.
llvm-svn: 174849
|
|
|
|
|
|
|
|
|
| |
This is some initial code for emitting the attribute groups into the bitcode.
NOTE: This format *may* change! Do not rely upon the attribute groups' bitcode
not changing.
llvm-svn: 174845
|
|
|
|
|
|
|
| |
Attribute groups are essentially all AttributeSets which are used by the
program. Enumerate them here.
llvm-svn: 174844
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 174550
|
|
|
|
|
|
| |
externally_initialized.
llvm-svn: 174340
|
|
|
|
|
|
|
|
|
| |
Rename the PARAMATTR_CODE_ENTRY to PARAMATTR_CODE_ENTRY_OLD. It will be replaced
by another encoding. Keep around the current LLVM attribute encoder/decoder
code, but move it to the bitcode directories so that no one's tempted to use
them.
llvm-svn: 174335
|
|
|
|
|
|
|
|
|
| |
We no longer accept an encoded integer as representing all of the
attributes. Convert this via the AttrBuilder class into an AttributeSet with the
correct representation (an AttributeSetImpl that holds a list of Attribute
objects).
llvm-svn: 173750
|
|
|
|
| |
llvm-svn: 173598
|
|
|
|
|
|
|
|
| |
The 'getSlot' function and its ilk allow introspection into the AttributeSet
class. However, that class should be opaque. Allow access through accessor
methods instead.
llvm-svn: 173522
|
|
|
|
| |
llvm-svn: 173499
|
|
|
|
|
|
|
|
|
| |
Previously we tried to infer it from the bit width size, with an added
IsIEEE argument for the PPC/IEEE 128-bit case, which had a default
value. This default value allowed bugs to creep in, where it was
inappropriate.
llvm-svn: 173138
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
it reason about the current bit position, which is always independent of the
underlying cursors word size.
llvm-svn: 173063
|
|
|
|
|
|
| |
bytes.
llvm-svn: 173062
|
|
|
|
|
|
| |
eagerly calling it.
llvm-svn: 172953
|
|
|
|
|
|
|
|
| |
new advance() APIs,
simplifying things and making a bunch of details more private to BitstreamCursor.
llvm-svn: 172947
|
|
|
|
|
|
|
|
| |
method to easy
the transition.
llvm-svn: 172940
|
|
|
|
| |
llvm-svn: 172931
|
|
|
|
|
|
|
|
| |
through a BitstreamCursor that produce it: advance() and
advanceSkippingSubblocks(), representing the two most common ways clients
want to walk through bitcode.
llvm-svn: 172919
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
hangings.
llvm-svn: 172020
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
llvm-svn: 171366
|
|
|
|
|
|
| |
method won't be sticking around.
llvm-svn: 171244
|
|
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170502
|
|
|
|
|
|
| |
some interfaces.
llvm-svn: 169712
|
|
|
|
| |
llvm-svn: 169710
|
|
|
|
|
|
| |
in the near future.
llvm-svn: 169651
|
|
|
|
|
|
|
|
|
|
| |
missed in the first pass because the script didn't yet handle include
guards.
Note that the script is now able to handle all of these headers without
manual edits. =]
llvm-svn: 169224
|
|
|
|
| |
llvm-svn: 169176
|
|
|
|
|
|
| |
space. SmallVector is still needed due to existing APIs growing their arguments
llvm-svn: 169157
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
|
|
|
|
|
|
| |
This is for backwards compatibility for pre-3.x bc files. The code reads the
code, but does nothing with it.
llvm-svn: 168779
|
|
|
|
|
|
| |
The dependent libraries feature was never used and has bit-rotted. Remove it.
llvm-svn: 168694
|
|
|
|
| |
llvm-svn: 168661
|
|
|
|
|
|
| |
Added in bitcode enum for the serializing of fast-math flags. Added in the reading/writing of fast-math flags from the OptimizationFlags record for BinaryOps.
llvm-svn: 168646
|
|
|
|
|
|
|
|
| |
- Widespread trailing space removal
- A dash of OCD spacing to block align enums
- joined a line that probably needed 80 cols a while back
llvm-svn: 168566
|
|
|
|
|
|
|
|
|
| |
When code deletes the context, the AttributeImpls that the AttrListPtr points to
are now invalid. Therefore, instead of keeping a separate managed static for the
AttrListPtrs that's reference counted, move it into the LLVMContext and delete
it when deleting the AttributeImpls.
llvm-svn: 168354
|
|
|
|
| |
llvm-svn: 168318
|
|
|
|
| |
llvm-svn: 168103
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously in a vector of pointers, the pointer couldn't be any pointer type,
it had to be a pointer to an integer or floating point type. This is a hassle
for dragonegg because the GCC vectorizer happily produces vectors of pointers
where the pointer is a pointer to a struct or whatever. Vector getelementptr
was restricted to just one index, but now that vectors of pointers can have
any pointer type it is more natural to allow arbitrary vector getelementptrs.
There is however the issue of struct GEPs, where if each lane chose different
struct fields then from that point on each lane will be working down into
unrelated types. This seems like too much pain for too little gain, so when
you have a vector struct index all the elements are required to be the same.
llvm-svn: 167828
|
|
|
|
|
|
| |
own class named AttrBuilder. No functionality change.
llvm-svn: 165960
|
|
|
|
|
|
|
|
|
|
| |
Convert the internal representation of the Attributes class into a pointer to an
opaque object that's uniqued by and stored in the LLVMContext object. The
Attributes class then becomes a thin wrapper around this opaque
object. Eventually, the internal representation will be expanded to include
attributes that represent code generation options, etc.
llvm-svn: 165917
|
|
|
|
|
|
|
| |
isa<> et al. automatically infer when the cast is an upcast (including a
self-cast), so these are no longer necessary.
llvm-svn: 165767
|