Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
1. The @ sign is no longer necessary.
2. We now support "function attributes" as parameter attribute 0.
3. Instead of locating the return type attributes after the type of a
function result, they are now located after the function header's
closing paranthesis and before any alignment or section options.
4. The way has been prepared for a new "noreturn" function attribute but
there is no support for recognizing it in the lexer nor doing anything
with it if it does get set.
5. The FunctionType::getParamAttrsText method now has support for
returning multiple attributes. This required a change in its interface.
I'm unhappy that this change leads to 6 new shift/reduce conflicts, but
in each case bison's decision to choose the shift is correct so there
shouldn't be any damage from these conflicts.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@32904 91177308-0d34-0410-b5e6-96231b3b80d8
The long awaited CAST patch. This introduces 12 new instructions into LLVM
to replace the cast instruction. Corresponding changes throughout LLVM are
provided. This passes llvm-test, llvm/test, and SPEC CPUINT2000 with the
exception of 175.vpr which fails only on a slight floating point output
difference.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@31931 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements the first increment for the Signless Types feature.
All changes pertain to removing the ConstantSInt and ConstantUInt classes
in favor of just using ConstantInt.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@31063 91177308-0d34-0410-b5e6-96231b3b80d8
eliminate its static dtors, without having code that depends on order of
initialization. Eliminate static ctors/dtors from Type.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@30667 91177308-0d34-0410-b5e6-96231b3b80d8
type when it gets refined. This allows us to hash on this crucial value.
* Fix several issues in TypeMap::RefineAbstractType that prevent it from
handling hash values that change correctly.
* Define hashTypeStructure to not always return 0. :)
This last part (which depends on the first two) speeds up gccld time on eon
from 3.78s to 2.75s with a release build (a 28% speedup!). This resolves
PR474.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24372 91177308-0d34-0410-b5e6-96231b3b80d8
former of which takes much less work than the later. This speeds up linking
eon from 3.749 to 3.637s with a release build (about 3%).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24338 91177308-0d34-0410-b5e6-96231b3b80d8
explanation from IRC:
|sabre| I think it's an order of evaluation thing
|sabre| for me, the RHS of the assignment is evaluated first
|sabre| getTypeDescription checks to see if ConcreteTypeDescription[Ty] contains anything
|sabre| since it doesn't, it computes and returns the value
|sabre| this gets put into the map.
|sabre| For you, the LHS is evaluated first.
|sabre| Map[Ty] (aka ConcreteTypeDescriptions[Ty]) inserts an empty string into the map, returning a reference
|sabre| getTypeDesc then sees the empty string in the map
|sabre| and returns it
|sabre| bork :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20394 91177308-0d34-0410-b5e6-96231b3b80d8
exponential behavior (bork!). This patch processes stuff with an
explicit SCC finder, allowing the algorithm to be more clear,
efficient, and also (as a bonus) correct! This gets us back to taking
0.6s to disassemble my horrible .bc file that previously took something
> 30 mins.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@16811 91177308-0d34-0410-b5e6-96231b3b80d8
(PromoteAbstractToConcrete), and to use a set to avoid recomputation.
In particular, this set eliminates the potentially exponential cases
from this little recursive algorithm.
On a particularly nasty testcase, llvm-dis on the .bc file went from 34
minutes (which is when I killed it, it still hadn't finished) to 0.57s.
Remember kids, exponential algorithms are bad.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@16772 91177308-0d34-0410-b5e6-96231b3b80d8
Move include/Config and include/Support into include/llvm/Config,
include/llvm/ADT and include/llvm/Support. From here on out, all LLVM
public header files must be under include/llvm/.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@16137 91177308-0d34-0410-b5e6-96231b3b80d8
