"In the existing code, if the load and the value to replace it with are
of different types *and* target data is available, it tries to use the
target data to coerce the replacement value to the type of the load.
Otherwise, it skips all effort to handle the type mismatch and just
feeds the wrongly-typed replacement value to replaceAllUsesWith, which
triggers an assertion.

The patch replaces it with an outer if checking for type mismatch, and
an inner if-else that checks whether target data is available and, if
not, returns false rather than trying to replace the load."

Patch by Kenneth Uildriks!

llvm-svn: 84739

llvm-svn: 84731

llvm-svn: 84667

the estimated code size and the number of blocks when deciding whether to
do a non-trivial unswitch. This protects it from some very undesirable
worst-case behavior on large numbers of loop-unswitchable conditions, such
as in the testcase in PR5259.

llvm-svn: 84661

When an incoming value for a PHI is updated, we must also updated all other
incoming values for the same BB to match, otherwise we create invalid PHIs.

llvm-svn: 84638

when the invoke had multiple return values: it set the lattice value only on the
extractvalue.
This caused the invoke's lattice value to remain the default (undefined), and
later propagated to extractvalue's operand, which incorrectly introduces
undefined behavior.

llvm-svn: 84637

numbering first class aggregate instructions while we're at it.

llvm-svn: 84547

Malloc calls are marked NoAlias, so the code below the isMalloc() check makes it redundant.  Removing the isMalloc() check.

llvm-svn: 84541

llvm-svn: 84533

where a loop's header is being split and it has predecessors which are not
contained by the most-nested loop which contains the loop.
This fixes PR5235.

llvm-svn: 84505

to name basic blocks "bb" instead of "BB", for consistency.

llvm-svn: 84502

instructions.

llvm-svn: 84404

llvm-svn: 84356

updating the callgraph when introducing a call.

llvm-svn: 84310

llvm-svn: 84299

Update testcases that rely on malloc insts being present.

Also prematurely remove MallocInst handling from IndMemRemoval and RaiseAllocations to help pass tests in this incremental step.

llvm-svn: 84292

llvm-svn: 84288

load, to help SelectionDAG fold them into the loads, unless
conditions are unfavorable.

llvm-svn: 84271

llvm-svn: 84256

Fix bug where array malloc with unexpected computation of the size argument resulted in MallocHelper 
identifying the malloc as a non-array malloc.  This broke GlobalOpt's optimization of stores of mallocs 
to global variables.

The fix is to classify malloc's into 3 categories:
1. non-array mallocs
2. array mallocs whose array size can be determined
3. mallocs that cannot be determined to be of type 1 or 2 and cannot be optimized

getMallocArraySize() returns NULL for category 3, and all users of this function must avoid their 
malloc optimization if this function returns NULL.

Eventually, currently unexpected codegen for computing the malloc's size argument will be supported in
isArrayMalloc() and getMallocArraySize(), extending malloc optimizations to those examples.

llvm-svn: 84199

don't bother every time going around the main worklist.  This speeds up a 
release-asserts opt -std-compile-opts on 403.gcc by about 4% (1.5s).  It
seems to speed up the most expensive instances of instcombine by ~10%.

llvm-svn: 84171

instruction (which disqualifies stores, unreachable, etc) and at least the
first operand is a constant.  This filters out a lot of obvious cases that
can't be folded.  Also, switch the IRBuilder to a TargetFolder, which tries
harder.

llvm-svn: 84170

llvm-svn: 84118

presence of PHI nodes.

llvm-svn: 84103

llvm-svn: 84049

Do not check use_empty() before replaceAllUsesWith(). This gives ValueHandles a chance to get properly updated.

llvm-svn: 84033

manually counting instructions.

llvm-svn: 84016

llvm-svn: 84001

llvm-svn: 83999

llvm-svn: 83998

for purposes other than inlining.

llvm-svn: 83997

this will increase the likelihood of common code getting sunk towards
the unwind.

llvm-svn: 83996

BasicBlocks, so that it doesn't blindly procede in the presence of
large individual BasicBlocks. This addresses a class of code-size
expansion problems.

llvm-svn: 83992

llvm-svn: 83908

llvm-svn: 83870

it to visit instructions from the start of the function to the
end of the function in the first path.  This greatly speeds up
some pathological cases (e.g. PR5150).

Try #3, this time with some unneeded debug info stuff removed
which was causing dead pointers to be added to the worklist.

llvm-svn: 83818

llvm-svn: 83817

it to visit instructions from the start of the function to the
end of the function in the first path.  This greatly speeds up
some pathological cases (e.g. PR5150). 

llvm-svn: 83814

into a shuffle even if it was used by another insertelement.  If the
visitation order of instcombine was wrong, this would turn a chain of
insertelements into a chain of shufflevectors, which was quite painful.

Since CollectShuffleElements handles these cases, the code can just
be nuked.

llvm-svn: 83810

new testcase.

llvm-svn: 83799