llvm-svn: 131482

llvm-svn: 131481

llvm-svn: 130895

llvm-svn: 130426

a nice and tidy:
  %x1 = load i32* %0, align 4
  %1 = icmp eq i32 %x1, 1179403647
  br i1 %1, label %if.then, label %if.end

instead of doing lots of loads and branches.  May the FreeBSD bootloader
long fit in its allocated space.

llvm-svn: 130416

llvm-svn: 130414

static functions instead of passing around tons of random ivars.

llvm-svn: 130403

llvm-svn: 130401

wider load would allow elimination of subsequent loads, and when the wider
load is still a native integer type.  This eliminates a ton of loads on 
various benchmarks involving struct fields, though it is somewhat hobbled
by clang not being very aggressive about field alignment.

This is yet another step along the way towards resolving PR6627.

llvm-svn: 130390

translation fails.  We were bailing out in some cases that would
cause us to miss GVN'ing some non-local cases away.

llvm-svn: 130206

return it as a clobber.  This allows GVN to do smart things.

Enhance GVN to be smart about the case when a small load is clobbered
by a larger overlapping load.  In this case, forward the value.  This
allows us to compile stuff like this:

int test(void *P) {
  int tmp = *(unsigned int*)P;
  return tmp+*((unsigned char*)P+1);
}

into:

_test:                                  ## @test
	movl	(%rdi), %ecx
	movzbl	%ch, %eax
	addl	%ecx, %eax
	ret

which has one load.  We already handled the case where the smaller
load was from a must-aliased base pointer.

llvm-svn: 130180

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

llvm-svn: 128537

llvm-svn: 128535

with BasicAA's DecomposeGEPExpression, which recently began
using a TargetData. This fixes PR8968, though the testcase
is awkward to reduce.

Also, update several off GetUnderlyingObject's users
which happen to have a TargetData handy to pass it in.

llvm-svn: 124134

llvm-svn: 123288

once at the beginning of GVN instead of once per iteration.

llvm-svn: 123278

llvm-svn: 123270

actually reached in the testcase in PR8954, but it's safe and good
practice.

llvm-svn: 123224

phi nodes.  It is called from MergeBlockIntoPredecessor which is 
called from GVN, which claims to preserve these.

I'm skeptical that this is the actual problem behind PR8954, but
this is a stab in the right direction.

llvm-svn: 123222

Don't bother value numbering instructions with void types in GVN. In theory this should allow us to insert
fewer things into the value numbering maps, but any speedup is beneath the noise threshold on my machine
on 403.gcc.

llvm-svn: 122844

llvm-svn: 122828

llvm-svn: 122827

llvm-svn: 122826

Clarify terminology, settling on referring to what was the "number table" as the "leader table", and
rename methods to make it much more clear what they're doing.

llvm-svn: 122823

llvm-svn: 122822

Branch instructions don't produce values, so there's no need to generate a value number for them.  This
avoids adding them to the various value numbering tables, resulting in a minor (~3%) speedup for GVN
on 40.gcc.

llvm-svn: 122819

llvm-svn: 122817

Use the new addEscapingValue callback to update GlobalsModRef when GVN adds PHIs of GEPs. For the moment,
have GlobalsModRef handle this conservatively by simply removing the value from its maps.

llvm-svn: 122787

almost-but-not-quite-identical code.  No intended functionality change.

llvm-svn: 122760

so that Dominators.h is *just* domtree.  Also prune #includes a bit.

llvm-svn: 122714

I still think that LVI should be handling this, but that capability is some ways off in the future,
and this matters for some significant benchmarks.

llvm-svn: 122378

llvm-svn: 122371

llvm-svn: 122362

llvm-svn: 122190

llvm-svn: 121921

function so that it can live in Analysis instead of
VMCore.

llvm-svn: 121885

llvm-svn: 120476

llvm-svn: 120474

llvm-svn: 119865

Completely rework the datastructure GVN uses to represent the value number to leader mapping.  Previously,
this was a tree of hashtables, and a query recursed into the table for the immediate dominator ad infinitum
if the initial lookup failed.  This led to really bad performance on tall, narrow CFGs.

We can instead replace it with what is conceptually a multimap of value numbers to leaders (actually
represented by a hashtable with a list of Value*'s as the value type), and then
determine which leader from that set to use very cheaply thanks to the DFS numberings maintained by
DominatorTree.  Because there are typically few duplicates of a given value, this scan tends to be
quite fast.  Additionally, we use a custom linked list and BumpPtr allocation to avoid any unnecessary
allocation in representing the value-side of the multimap.

This change brings with it a 15% (!) improvement in the total running time of GVN on 403.gcc, which I
think is pretty good considering that includes all the "real work" being done by MemDep as well.

The one downside to this approach is that we can no longer use GVN to perform simple conditional progation,
but that seems like an acceptable loss since we now have LVI and CorrelatedValuePropagation to pick up
the slack.  If you see conditional propagation that's not happening, please file bugs against LVI or CVP.

llvm-svn: 119714