llvm-svn: 131604

Start trying to make InstCombine preserve more debug info.  The idea here is to set the debug location on the IRBuilder, which will be then right location in most cases.  This should magically give many transformations debug locations, and fixing places which are missing a debug location will usually just means changing the code creating it to use the IRBuilder.

As an example, the change to InstCombineCalls catches a common case where a call to a bitcast of a function is rewritten.

Chris, does this approach look reasonable?

llvm-svn: 131516

llvm-svn: 131512

effective in avoiding recomputation of LCSSA form; the widespread
use of instsimplify (which looks through phi nodes) means it was
not preserving LCSSA form anyway; and instcombine is no longer
scheduled in the middle of the loop passes so this doesn't matter
anymore.

llvm-svn: 130301

space info. We crash with an assert in this case. This change checks that the
address space of the bitcasted pointer is the same as the gep ptr.

llvm-svn: 128884

PHINode::Create() giving the (known or expected) number of operands.

llvm-svn: 128537

llvm-svn: 128406

This is done by lowering dbg.declare intrinsic into dbg.value intrinsic.
Radar 9143931.

llvm-svn: 127834

llvm-svn: 125547

reassociation. No testcase, because I wasn't able to create a testcase
which actually demonstrates a problem.

llvm-svn: 124713

llvm-svn: 123968

llvm-svn: 123965

a select. A vector select is pairwise on each element so we'd need a new
condition with the right number of elements to select on. Fixes PR8994.

llvm-svn: 123963

llvm-svn: 123569

multiple uses.  In some cases, all the uses are the same operation,
so instcombine can go ahead and promote the phi.  In the testcase
this pushes an add out of the loop.

llvm-svn: 123568

first line of the function because it isn't a good idea, even for compares.

llvm-svn: 123566

llvm-svn: 123565

llvm-svn: 123564

if both A op B and A op C simplify.  This fires fairly often but doesn't
make that much difference.  On gcc-as-one-file it removes two "and"s and
turns one branch into a select.

llvm-svn: 122399

instcombine is compared to instsimplify.

llvm-svn: 122397

llvm-svn: 122204

llvm-svn: 122183

Transform (extractvalue (load P), ...) to (load (gep P, 0, ...)) if the load has no other uses, shrinking the load.

llvm-svn: 120323

llvm-svn: 120051

Stylistic improvement suggested by Frits van Bommel.

llvm-svn: 120026

llvm-svn: 120025

fairly systematic way in instcombine.  Some of these cases were already dealt
with, in which case I removed the existing code.  The case of Add has a bunch of
funky logic which covers some of this plus a few variants (considers shifts to be
a form of multiplication), which I didn't touch.  The simplification performed is:
A*B+A*C -> A*(B+C).  The improvement is to do this in cases that were not already
handled [such as A*B-A*C -> A*(B-C), which was reported on the mailing list], and
also to do it more often by not checking for "only one use" if "B+C" simplifies.

llvm-svn: 120024

then replace the index with zero.

llvm-svn: 119974

InstructionSimplify.

llvm-svn: 119970

SimplifyAssociativeOrCommutative) "(A op C1) op C2" -> "A op (C1 op C2)",
which previously was only done if C1 and C2 were constants, to occur whenever
"C1 op C2" simplifies (a la InstructionSimplify).  Since the simplifying operand
combination can no longer be assumed to be the right-hand terms, consider all of
the possible permutations.  When compiling "gcc as one big file", transform 2
(i.e. using right-hand operands) fires about 4000 times but it has to be said
that most of the time the simplifying operands are both constants.  Transforms
3, 4 and 5 each fired once.  Transform 6, which is an existing transform that
I didn't change, never fired.  With this change, the testcase is now optimized
perfectly with one run of instcombine (previously it required instcombine +
reassociate + instcombine, and it may just have been luck that this worked).

llvm-svn: 119002

llvm-svn: 117213

llvm-svn: 115996

llvm-svn: 115965

llvm-svn: 109045

llvm-svn: 107972

llvm-svn: 106736

to null.  Patch by Matti Niemenmaa.

llvm-svn: 104871

Probably the best way to know that all getOperand() calls have been handled
is to replace that API instead of updating.

llvm-svn: 101579

with a fix for self-hosting

rotate CallInst operands, i.e. move callee to the back
of the operand array

the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary

llvm-svn: 101465

llvm-svn: 101434