llvm-svn: 92211

SDISel.  This optimization was causing simplifylibcalls to 
introduce type-unsafe nastiness.  This is the first step, I'll be 
expanding the memcmp optimizations shortly, covering things that
we really really wouldn't want simplifylibcalls to do.

llvm-svn: 92098

llvm-svn: 92084

Remove dump routine and the associated Debug.h from a header.  Patch up
other files to compensate.

llvm-svn: 92075

lowering code and update testcases.

llvm-svn: 91979

load is needed when we have a small store into a large alloca (at which 
point we get a load/insert/store sequence), but when you do a full-sized
store, this load ends up being dead.

This dead load is bad in really large nasty testcases where the load ends
up causing mem2reg to insert large chains of dependent phi nodes which only
ADCE can delete.  Instead of doing this, just don't insert the dead load.

This fixes rdar://6864035

llvm-svn: 91917

llvm-svn: 91916

missing check that an array reference doesn't go past the end of the array,
and remove some redundant checks for in-bound array and vector references
that are no longer needed.

llvm-svn: 91897

by merging all returns in a function into a single one, but simplifycfg 
currently likes to duplicate the return (an unfortunate choice!)

llvm-svn: 91890

instead of stored.  This reduces memdep memory usage, and also eliminates a bunch of
weakvh's.  This speeds up gvn on gcc.c-torture/20001226-1.c from 23.9s to 8.45s (2.8x)
on a different machine than earlier.

llvm-svn: 91885

llvm-svn: 91875

llvm-svn: 91853

load to avoid even messing around with SSAUpdate at all.  In this case (which
is very common, we can just use the input value directly).

This speeds up GVN time on gcc.c-torture/20001226-1.c from 36.4s to 16.3s,
which still isn't great, but substantially better and this is a simple speedup
that applies to lots of different cases.

llvm-svn: 91851

llvm-svn: 91849

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