llvm-svn: 135375

Added recognition for signed add/sub/mul with overflow intrinsics to GVN as per Chris and Frits suggestion.

llvm-svn: 134777

Make GVN look through extractvalues for recognised intrinsics. GVN can then CSE ops that match values produced by the intrinsics.

llvm-svn: 134677

Change various bits of code to make better use of the existing PHINode
API, to insulate them from forthcoming changes in how PHINodes store
their operands.

llvm-svn: 133434

Add "unknown" results for memdep, which mean "I don't know whether a dependence for the given instruction exists in the given block".  This cleans up all the existing hacks in memdep which represent this concept by returning clobber with various unrelated instructions.

llvm-svn: 133031

causing it to get into infinite loops when it would widen a 
load (which can necessarily leave around dead loads).

llvm-svn: 131847

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