This allows SCEV users to effectively calculate trip count.
LSR later on transforms back integer IVs to floating point IVs
later on to avoid int-to-float casts inside the loop.

llvm-svn: 58625

LoopPass*.
 - Although less precise, this means they can be used in clients
   without RTTI (who would otherwise need to include LoopPass.h, which
   eventually includes things using dynamic_cast). This was the
   simplest solution that presented itself, but I am happy to use a
   better one if available.

llvm-svn: 58010

llvm-svn: 56056

extend the type of induction variable.

llvm-svn: 56017

llvm-svn: 55861

llvm-svn: 55779

instead of having it call getIterationCount again.

llvm-svn: 54380

llvm-svn: 52616

llvm-svn: 52251

use it instead of duplicating its functionality.

llvm-svn: 51499

API change for {BinaryOperator|CmpInst|CastInst}::create*() --> Create. Legacy interfaces will be in place for some time.  (Merge from use-diet branch.)

llvm-svn: 51200

several things that were neither in an anonymous namespace nor static
but not intended to be global.

llvm-svn: 51017

Specifically, introduction of XXX::Create methods
for Users that have a potentially variable number of
Uses.

llvm-svn: 49277

llvm-svn: 45418

SCEV subclasses to being non-static member functions of the ScalarEvolution
class.

llvm-svn: 43224

llvm-svn: 41798

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

llvm-svn: 41697

llvm-svn: 41207

llvm-svn: 37751

deleteValueFromRecords and loosen the types to all it to accept
Value* instead of just Instruction*, since this is what
ScalarEvolution uses internally anyway. This allows more flexibility
for future uses.

llvm-svn: 37657

integer constant SCEV.

llvm-svn: 37596

This created an ambiguity for expandInTy to decide when to use
sign-extension or zero-extension, but it turns out that most of its callers
don't actually need a type conversion, now that LLVM types don't have
explicit signedness. Drop expandInTy in favor of plain expand, and change
the few places that actually need a type conversion to do it themselves.

llvm-svn: 37591

This is the obviously correct part of the fix for PR1487.

llvm-svn: 37457

llvm-svn: 36873

llvm-svn: 36662

Due to darwin gcc bug, one version of darwin linker coalesces
static const int, which defauts PassID based pass identification.

llvm-svn: 36652

llvm-svn: 36632

llvm-svn: 35003

would scan the entire loop body, then scan all users of instructions in the
loop, looking for users outside the loop.  Now, since we know that the
loop is in LCSSA form, we know that any users outside the loop will be LCSSA
phi nodes.  Just scan them.

This speeds up indvars significantly.

llvm-svn: 34898

This makes -indvars require and use LCSSA, updating it as appropriate.

llvm-svn: 34896

llvm-svn: 34891

Constant::isNullValue() in situations where it is possible.

llvm-svn: 34821

llvm-svn: 34176

the Transforms library. This reduces debug library size by 132 KB, debug
binary size by 376 KB, and reduces link time for llvm tools slightly.

llvm-svn: 33939

llvm-svn: 33715

llvm-svn: 33693

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: 33218

llvm-svn: 33150

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