two-element arrays.  After restructuring the SROA code, it was not safe to
do this without adding more checking.  It is not clear that this special-case
has really been useful, and removing this simplifies the code quite a bit.

llvm-svn: 91828

implement some optimizations for MIN(MIN()) and MAX(MAX()) and 
MIN(MAX()) etc.  This substantially improves the code in PR5822 but
doesn't kick in much elsewhere.  2 max's were optimized in 
pairlocalalign and one in smg2000.

llvm-svn: 91814

Use the presence of NSW/NUW to fold "icmp (x+cst), x" to a constant in
cases where it would otherwise be undefined behavior.

Surprisingly (to me at least), this triggers hundreds of the times in
a few benchmarks: lencode, ldecode, and 466.h264ref seem to *really*
like this.

llvm-svn: 91812

a bunch in lencode, ldecod, spass, 176.gcc, 252.eon, among others.  It is 
also the first part of PR5822

llvm-svn: 91811

where instcombine would have to split a critical edge due to a
phi node of an invoke.  Since instcombine can't change the CFG,
it has to bail out from doing the transformation.

llvm-svn: 91763

* change FindElementAndOffset to return a uint64_t instead of unsigned, and
  to identify the type to be used for that result in a GEP instruction.
* move "isa<ConstantInt>" to be first in conditional.
* replace some dyn_casts with casts.
* add a comment about handling mem intrinsics.

llvm-svn: 91762

bootstrap.  This also replaces the WeakVH references that Chris objected to
with normal Value references.

llvm-svn: 91711

multiple uses.  (The construct in question was found in gcc.)

llvm-svn: 91675

llvm-svn: 91666

contains another loop, or an instruction. The loop form is
substantially more efficient on large loops than the typical
code it replaces.

llvm-svn: 91654

llvm-svn: 91653

llvm-svn: 91647

of 91296 that caused trouble -- the Processed list needs to be
preserved for the livetime of the pass, as AddUsersIfInteresting
is called from other passes.

llvm-svn: 91641

llvm-svn: 91631

llvm-svn: 91624

to memcpy. (Such a memcpy is technically illegal, but in practice is safe
and is generated by struct self-assignment in C code.)

llvm-svn: 91621

llvm-svn: 91607

Revert 91280-91283, 91286-91289, 91291, 91293, 91295-91296. It apparently introduced a non-deterministic behavior in the optimizer somewhere.

llvm-svn: 91598

Reapply r91459, it was only unmasking the bug, and since TOT is still broken having it reverted does no good.

llvm-svn: 91559

problem", this broke llvm-gcc bootstrap for release builds on
x86_64-apple-darwin10.

This reverts commit db22309800b224a9f5f51baf76071d7a93ce59c9.

llvm-svn: 91534

miscompile (i386.o miscompares) but it happens both with and without
this patch.

llvm-svn: 91532

Will reapply with a fix when I get a chance.

llvm-svn: 91486

found last time.  Instead of trying to modify the IR while iterating over it,
I've change it to keep a list of WeakVH references to dead instructions, and
then delete those instructions later.  I also added some special case code to
detect and handle the situation when both operands of a memcpy intrinsic are
referencing the same alloca.

llvm-svn: 91459

llvm-svn: 91438

llvm-svn: 91432

llvm-svn: 91428

isPodLike type trait.  This is a generally useful type trait for
more than just DenseMap, and we really care about whether something
acts like a pod, not whether it really is a pod.

llvm-svn: 91421

condition was inverted when the code was converted to contains().

llvm-svn: 91295

llvm-svn: 91293

the ScalarEvolution pointer into the functions which need it.

llvm-svn: 91289

llvm-svn: 91288

llvm-svn: 91287

llvm-svn: 91283

llvm-svn: 91282

SCEVExpander does this automatically.

llvm-svn: 91281

llvm-svn: 91280

sent to Bob.

llvm-svn: 91268

While scanning through the uses of an alloca, keep track of the current offset
relative to the start of the alloca, and check memory references to see if
the offset & size correspond to a component within the alloca.  This has the
nice benefit of unifying much of the code from isSafeUseOfAllocation,
isSafeElementUse, and isSafeUseOfBitCastedAllocation.  The code to rewrite
the uses of a promoted alloca, after it is determined to be safe, is
reorganized in the same way.

Also, when rewriting GEP instructions, mark them as "in-bounds" since all the
indices are known to be safe.

llvm-svn: 91184

of the loop. We could get to this condition via indirect
branches.

llvm-svn: 91009

value size.  This only manifested when memdep inprecisely returns clobber,
which is do to a caching issue in the PR5744 testcase.  We can 'efficiently
emulate' this by using '-no-aa'

llvm-svn: 91004