llvm-svn: 43129

Update GEP constructors to use an iterator interface to fix
GLIBCXX_DEBUG issues.

llvm-svn: 41697

Update InvokeInst to work like CallInst

llvm-svn: 41506

This eliminates a conditional on that path, and ensures ICmpInst/FCmpInst
both have an out-of-line virtual method to home the class.

llvm-svn: 41371

New CallInst interface to address GLIBCXX_DEBUG errors caused by
indexing an empty std::vector.

Updates to all clients.

llvm-svn: 40660

end of a BasicBlock and have an alignment parameter.

llvm-svn: 40016

llvm-svn: 37585

llvm-svn: 36995

llvm-svn: 36515

llvm-svn: 36349

Add reference counting to ParamAttrsList and make use of it in Function,
CallInst and InvokeInst classes.

llvm-svn: 36346

Make ParamAttrsList objects unique. You can no longer directly create or
destroy them but instead must go through the ParamAttrsList::get()
interface.

llvm-svn: 36327

llvm-svn: 36309

add support for alignment attributes on load/store instructions

llvm-svn: 36301

Writing it twice in the same day was too much for me.

llvm-svn: 35978

not retain that name. Not noticed because AsmParser always sets name after
construction. However, llvm2cpp noticed.

llvm-svn: 35903

* Add ParamAttrs to InvokeInst class too.
* Make sure all initializes of ParamAttrs in CallInst and InvokeInst are 0
* Destruct the ParamAttrs in Call/Invoke destructors to avoid memory
  leaks. This will change when ParamAttrsList is uniquified but needs to
  be correct until then.

llvm-svn: 35824

* Add ParamAttrList pointers to Function and CallInst.
* Move the implementation of ParamAttrList from Type.cpp to Function.cpp

llvm-svn: 35818

llvm-svn: 35265

functional change with this patch.

llvm-svn: 34806

from a predicate and an APInt. This is removed from ConstantRange class
so that ConstantRange doesn't have to depend on lib/VMCore.

llvm-svn: 34760

solve a crash in -instcombine -debug that was hit while investigating PR1217

llvm-svn: 34544

Change use of "packed" term to "vector" in comments, strings, variable
names, etc.

llvm-svn: 34300

Rename PackedType -> VectorType, ConstantPacked -> ConstantVector, and
PackedTyID -> VectorTyID. No functional changes.

llvm-svn: 34293

This speeds up bcreading by 1.5%.

llvm-svn: 34233

llvm-svn: 34228

llvm-svn: 34214

llvm-svn: 34213

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

llvm-svn: 33747

GEP constructors.

llvm-svn: 33726

llvm-svn: 33708

This allows us to eliminate many temporary vectors, and theirassociated malloc/free pairs.

llvm-svn: 33692

llvm-svn: 33519

Clean up handling of isFloatingPoint() and dealing with PackedType.
Patch by Gordon Henriksen!

llvm-svn: 33415

Expose the previously hidden checkCast function as CastInst::castIsValid.

llvm-svn: 33282

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

llvm-svn: 33223

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

llvm-svn: 33076