Commit Graph

170 Commits

Author SHA1 Message Date
Bill Wendling 3b65187d2f Revert s/Raw/getBitMask/g name change. This is possibly causing LTO test hangings.
llvm-svn: 172020
2013-01-09 23:36:50 +00:00
Bill Wendling f927ad34e7 Alter the hasing computation when inserting into the folding set.
llvm-svn: 171960
2013-01-09 09:26:23 +00:00
Bill Wendling 0ec3c5ca80 Forgot the namespace identifier.
llvm-svn: 171924
2013-01-09 00:32:55 +00:00
Bill Wendling 69fa5c0d99 Add the integer value of the ConstantInt instead of the Constant* value.
This is causing some problems. The root cause is unknown at this time.

llvm-svn: 171923
2013-01-09 00:32:08 +00:00
Bill Wendling 096f544edc Rough out a new c'tor for the AttrBuilder class.
This c'tor takes the AttributeSet class as the parameter. It will eventually
grab the attributes from the specified index and create a new attribute builder
with those attributes.

llvm-svn: 171712
2013-01-07 08:24:35 +00:00
Benjamin Kramer d60321ba19 Attribute: Make hashes match when looking up AttributeImpls.
This isn't optimal either but fixes a massive compile time regression from the
attribute uniquing work.

llvm-svn: 171624
2013-01-05 12:08:00 +00:00
Chandler Carruth 5394e11a55 Switch the empty and tombstone key enumerators to not have explicit
values -- that's not required to fix the bug that was cropping up, and
the values selected made the enumeration's underlying type signed and
introduced some warnings. This fixes the -Werror build.

The underlying issue here was that the DenseMapInfo was casting values
completely outside the range of the underlying storage of the
enumeration to the enumeration's type. GCC went and "optimized" that
into infloops and other misbehavior. By providing designated special
values for these keys in the dense map, we ensure they are indeed
representable and that they won't be used for anything else.

It might be better to reuse None for the empty key and have the
tombstone share the value of the sentinel enumerator, but honestly
having 2 extra enumerators seemed not to matter and this seems a bit
simpler. I'll let Bill shuffle this around (or ask me to shuffle it
around) if he prefers it to look a different way.

I also made the switch a bit more clear (and produce a better assert)
that the enumerators are *never* going to show up and are errors if they
do.

llvm-svn: 171614
2013-01-05 08:47:26 +00:00
NAKAMURA Takumi c91006f741 IR/Attributes: Provide EmptyKey and TombstoneKey in part of enum, as workaround for gcc-4.4 take #2.
I will investigate, later, what was wrong. I am too tired for now.

llvm-svn: 171611
2013-01-05 07:55:47 +00:00
Bill Wendling 960f52a132 Add a method to create an AttributeSet from an AttrBuilder.
The Attribute class is eventually going to represent one attribute. So we need
this class to create the set of attributes. Add some iterator methods to the
builder to access its internal bits in a nice way.

llvm-svn: 171586
2013-01-05 01:36:54 +00:00
Bill Wendling cd330348f5 Get rid of the 'Bits' mask in the attribute builder.
The bit mask thing will be a thing of the past. It's not extensible enough. Get
rid of its use here. Opt instead for using a vector to hold the attributes.

Note: Some of this code will become obsolete once the rewrite is further along.
llvm-svn: 171553
2013-01-04 23:27:34 +00:00
Bill Wendling 9ac69f9d37 General cleanups.
* Remove dead methods.
* Use the 'operator==' method instead of 'contains', which isn't needed.
* Fix some comments.

No functionality change.

llvm-svn: 171523
2013-01-04 20:54:35 +00:00
Bill Wendling c0df112941 Revert everything to r171366 to try to fix the build.
llvm-svn: 171450
2013-01-03 02:01:50 +00:00
Bill Wendling 04949fa998 Try again to revert the bad patch. The tree was reverted for some unknown reason
before the last time.

--- Reverse-merging r171442 into '.':
U    include/llvm/IR/Attributes.h
U    lib/IR/Attributes.cpp
U    lib/IR/AttributeImpl.h

llvm-svn: 171448
2013-01-03 01:54:39 +00:00
Bill Wendling 40785ae18f Revert patch. Something snuck in there that shouldn't be.
--- Reverse-merging r171441 into '.':
U    include/llvm/IR/Attributes.h
U    lib/IR/Attributes.cpp

llvm-svn: 171444
2013-01-03 01:46:27 +00:00
Bill Wendling af9a90cc00 Remove the 'contains' methods in favor of the 'operator==' method.
The 'operator==' method is a bit clearer and much less verbose for somethings
that should have only one value. Remove from the AttrBuilder for consistency.

llvm-svn: 171442
2013-01-03 01:43:05 +00:00
NAKAMURA Takumi cedab7ecf3 Revert r171427, "An intermediate step in the Attributes rewrite."
llvm-svn: 171441
2013-01-03 01:42:06 +00:00
Bill Wendling 0793f4501c Make the type signature more strict.
llvm-svn: 171434
2013-01-03 00:46:43 +00:00
Bill Wendling 91055cfbaf An intermediate step in the Attributes rewrite.
Modify the AttrBuilder class to store the attributes as a set instead of as a
bit mask. The Attribute class will represent only one attribute instead of a
collection of attributes.

This is the wave of the future!

llvm-svn: 171427
2013-01-02 23:45:09 +00:00
Chandler Carruth 9fb823bbd4 Move all of the header files which are involved in modelling the LLVM IR
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
2013-01-02 11:36:10 +00:00
Chandler Carruth ef860a2488 Rename VMCore directory to IR.
Aside from moving the actual files, this patch only updates the build
system and the source file comments under lib/... that are relevant.

I'll be updating other docs and other files in smaller subsequnet
commits.

While I've tried to test this, but it is entirely possible that there
will still be some build system fallout.

Also, note that I've not changed the library name itself: libLLVMCore.a
is still the library name. I'd be interested in others' opinions about
whether we should rename this as well (I think we should, just not sure
what it might break)

llvm-svn: 171359
2013-01-02 09:10:48 +00:00