This patch replaces the SymbolTable class with ValueSymbolTable which does
not support types planes. This means that all symbol names in LLVM must now
be unique. The patch addresses the necessary changes to deal with this and
removes code no longer needed as a result. This completes the bulk of the
changes for this PR. Some cleanup patches will follow.
llvm-svn: 33918
This feature is needed in order to support shifts of more than 255 bits
on large integer types. This changes the syntax for llvm assembly to
make shl, ashr and lshr instructions look like a binary operator:
shl i32 %X, 1
instead of
shl i32 %X, i8 1
Additionally, this should help a few passes perform additional optimizations.
llvm-svn: 33776
This is the final patch for this PR. It implements some minor cleanup
in the use of IntegerType, to wit:
1. Type::getIntegerTypeMask -> IntegerType::getBitMask
2. Type::Int*Ty changed to IntegerType* from Type*
3. ConstantInt::getType() returns IntegerType* now, not Type*
This also fixes PR1120.
Patch by Sheng Zhou.
llvm-svn: 33370
rename Type::getIntegralTypeMask to Type::getIntegerTypeMask.
This makes naming much more consistent. For example, there are now no longer any
instances of IntegerType that are not considered isInteger! :)
llvm-svn: 33225
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.
llvm-svn: 33113
recommended that getBoolValue be replaced with getZExtValue and that
get(bool) be replaced by get(const Type*, uint64_t). This implements
those changes.
llvm-svn: 33110
This patch removes the SetCC instructions and replaces them with the ICmp
and FCmp instructions. The SetCondInst instruction has been removed and
been replaced with ICmpInst and FCmpInst.
llvm-svn: 32751
Remove the getMaxValue and getMinValue functions from ConstantIntegral.
They don't make sense for a signless type. Also, for isMaxValue and
isMinValue, have the caller provided the signedness rather than obtaining
it from the constant's type.
llvm-svn: 32287
CastInst and ConstantExpr that allow the signedness to be explicitly passed
in and reliance on signedness removed from getCastOpcode. These are
temporary measures useful during the conversion of inferred casts.
llvm-svn: 32164
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.
llvm-svn: 31931
This patch converts the old SHR instruction into two instructions,
AShr (Arithmetic) and LShr (Logical). The Shr instructions now are not
dependent on the sign of their operands.
llvm-svn: 31542
Make necessary changes to support DIV -> [SUF]Div. This changes llvm to
have three division instructions: signed, unsigned, floating point. The
bytecode and assembler are bacwards compatible, however.
llvm-svn: 31195
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.
llvm-svn: 31063
string. Instead of specifying the length, just specify whether the user
wants a terminating null or not. The default is "true" to retain the same
behavior as previously provided by this function.
llvm-svn: 28562
implementation always added a null byte to the end of the string. It turns
out that this is not always wanted. By adding a length parameter we preserve
this behavior when length==0 (default value) but also allow other lengths
(not null terminated) to be created.
llvm-svn: 28552
Implement the suggested check to ensure that out-of-range float constants
don't get accepted by LLVM accidentally. Adjust the supporting test cases
as well.
llvm-svn: 24963
When moving constant entries in 'Map' if the entry is the representative
constant for the abstractypemap, make sure to update it as well. This
fixes the bcreader failures from last night on several C++ apps.
llvm-svn: 23628
creating the keys and doing comparisons to index into 'Map' takes a lot
of time. For these large constants, keep an inverse map so that 'remove'
and move operations are much faster.
This speeds up a release build of the bc reader on Eric's nasty python
bytecode file from 1:39 to 1:00s.
llvm-svn: 23624
constant arrays in place instead of reallocating them and replaceAllUsesOf'ing
the result. This speeds up a release build of the bcreader from:
136.987u 120.866s 4:24.38
to
49.790u 49.890s 1:40.14
... a 2.6x speedup parsing a large python bc file.
llvm-svn: 23614
This speeds up isa/dyncast/etc for constants, and also makes them smaller.
For example, the text section of a release build of InstCombine.cpp shrinks
from 230037 bytes to 216363 bytes, a 6% reduction.
llvm-svn: 23467
Test the range of float constants to ensure we are not attempting to create a \
float constant using a double value that is out of range for a float
llvm-svn: 18585
well as a vector of constant*'s. It turns out that this is more efficient
and all of the clients want to do that, so we should cater to them.
llvm-svn: 16923
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/.
llvm-svn: 16137
initializers for constant structs and arrays take constant space, instead of
space proportinal to the number of elements. This reduces the memory usage of
the LLVM compiler by hundreds of megabytes when compiling some nasty SPEC95
benchmarks.
llvm-svn: 11470
'Constant', instead of specific subclass pointers. In the future, these will
return an instance of ConstantAggregateZero if all of the inputs are zeros.
llvm-svn: 11467
Basically we store floating point values as their integral components, instead of relying
on the semantics of floating point < to differentiate between values. This is likely to
make the map search be faster anyway.
llvm-svn: 11064
out that the problem was actually the writer writing out a 'null' value
because it didn't normalize it. This fixes:
test/Regression/Assembler/2004-01-22-FloatNormalization.ll
llvm-svn: 10967
Move a bunch of (now) private stuff from ConstantFolding.h into
ConstantFolding.cpp.
This _finally_ gets us to a place where we have a sane constant folder. The
rules are:
1. LLVM clients now use ConstantExpr::get* methods to fold constants. If they
cannot be folded, a constantexpr is created, so these methods always return
valid Constant*'s.
2. The implementation of ConstantExpr::get* uses the functions exposed by
ConstantFolding.h to try to fold constants. If they cannot be folded,
they should return a null pointer.
3. The implementation of ConstantFolding can do whatever it wants, and only
has one client (Constants.cpp)
This cuts down on the wierd dependencies, and eliminates the two interfaces.
The old constanthandling interface was especially bad for clients to use
because almost none of them took the failure condition into consideration,
thus leading to obscure problems.
llvm-svn: 10807
constants as necessary due to type resolution. With this change, the
following spec benchmarks now link: 176.gcc, 177.mesa, 252.eon,
253.perlbmk, & 300.twolf. IOW, all SPEC INT and FP benchmarks now link.
llvm-svn: 8853
This was a problem with constants having their types resolved to some new type,
but there was already a constant of the new type created. Before, these types
were never merged together, now they are.
llvm-svn: 6314
when they are destroyed, which makes Constant::destroyConstant an actually
useful external interface. Expose these methods publicly.
- Implement destroyConstant on ConstPointerNull so that destroyConstant can
be used on any derived type constant safely.
llvm-svn: 3379
* Correctly delete TypeHandles in AsmParser. In addition to not leaking
memory, this prevents a bug that could have occurred when a type got
resolved that the constexpr was using
* Check for errors in the AsmParser instead of hitting assertion failures
deep in the code
* Simplify the interface to the ConstantExpr class, removing unneccesary
parameters to the ::get* methods.
* Rename the 'getelementptr' version of ConstantExpr::get to
ConstantExpr::getGetElementPtr
llvm-svn: 3161
constants using operators such as cast, getelementptr, add, shl, etc.
Note that a ConstantExpr can be of any type, so classof() in most
other subclasses (that discriminate by type) have to check that it
is also not a ConstantExpr.
llvm-svn: 2901
