Disable null pointer folding transforms for non-generic address spaces. This should probably be a target-specific predicate based on address space. That way for targets where this isn't applicable the predicate can be optimized away.

llvm-svn: 45403

of comparing begin() and end().

llvm-svn: 42585

pacifies g++-4.2.

llvm-svn: 40089

Test case at Transformations/SCCP/2007-05-16-InvokeCrash.ll

llvm-svn: 37185

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

llvm-svn: 34904

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

llvm-svn: 34293

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

llvm-svn: 33796

llvm-svn: 33794

IPSCCP 3.3% on kimwitu.

llvm-svn: 33793

a release-assert build on kimwitu++.

llvm-svn: 33792

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

llvm-svn: 33672

confusion with external linkage types.

llvm-svn: 33663

llvm-svn: 33175

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

llvm-svn: 33076

Merge ConstantIntegral and ConstantBool into ConstantInt.
Remove ConstantIntegral and ConstantBool from LLVM.

llvm-svn: 33073

llvm-svn: 32858

llvm-svn: 32827

llvm-svn: 32803

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

code to handle instructions as well, so that we properly fold things like
X & undef -> 0.
This fixes Transforms/SCCP/2006-12-19-UndefBug.ll

llvm-svn: 32715

converted, we lose a static initializer.  This also allows GCC to emit warnings
about unused statistics.

llvm-svn: 32690

llvm-svn: 32469

now cerr, cout, and NullStream resp.

llvm-svn: 32298

is 'unsigned'.

llvm-svn: 32279

for now.

llvm-svn: 32208

llvm-svn: 31923

Turn on -Wunused and -Wno-unused-parameter. Clean up most of the resulting
fall out by removing unused variables. Remaining warnings have to do with
unused functions (I didn't want to delete code without review) and unused
variables in generated code. Maintainers should clean up the remaining
issues when they see them. All changes pass DejaGnu tests and Olden.

llvm-svn: 31380

Prolangs-C/agrep and SCCP/2006-10-23-IPSCCP-Crash.ll

llvm-svn: 31132

1. Better document what is going on here.
2. Only hack on one branch per iteration, making the results less conservative.
3. Handle the problematic case by marking edges executable instead of by
   playing with value lattice states.  This is far less pessimistic, and fixes
   SCCP/ipsccp-gvar.ll.

llvm-svn: 31106