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

llvm-svn: 91645

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

about the potential use of these uninitialized members under certain conditions.

llvm-svn: 91239

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

llvm-svn: 90999

llvm-svn: 90990

clobbers to forward pieces of large stores to small loads, we need to consider
the properly phi translated pointer in the store block.

llvm-svn: 90978

implicitly constant folds.

llvm-svn: 90977

llvm-svn: 90975

to require the load ty/ptr to be passed in, no functionality change.

llvm-svn: 90960

and pointer instead of the load.  No functionality change.

llvm-svn: 90959