llvm-svn: 53470

Use information already present in the ValueTable to fast-fail when we know there won't be a value number match.  This speeds up GVN on a case where there are very few redundancies by ~25%.

llvm-svn: 53108

llvm-svn: 53040

llvm-svn: 53032

llvm-svn: 52643

Tighten the conditions under which we do PRE, remove some unneeded code, and correct our preserved analyses list, since we
do now change the CFG by splitting critical edges during PRE.

llvm-svn: 52631

llvm-svn: 52574

llvm-svn: 52531

Change around the data structures used to store availability sets, resulting in a GVN+PRE that is faster that GVN alone was before.

llvm-svn: 52521

llvm-svn: 52518

once benchmarking is completed.

llvm-svn: 52506

llvm-svn: 52505

This fixes a failure on povray.

llvm-svn: 52499

GVN expects that all inputs which to an instruction fall somewhere in the value
hierarchy, which isn't true for these.

llvm-svn: 52496

llvm-svn: 52472

Add local PRE to GVN.  This only operates in cases where it would not increase code size, namely when the instantiated expression
would only need to be created in one predecessor.

llvm-svn: 52471

We don't want to find dependencies within the same block in this case.  It leads to incorrect results because
we're detecting something at or after the call we're querying on.

llvm-svn: 52433

llvm-svn: 52242

deprecated by the GVN and GVNPRE passes.

llvm-svn: 51983

llvm-svn: 51955

llvm-svn: 51230

bug as well as a missed optimization.  We weren't properly checking for local
dependencies before moving on to non-local ones when doing non-local read-only 
call CSE.

llvm-svn: 51082

llvm-svn: 51035

llvm-svn: 51024

llvm-svn: 50995

Move the various analyses used by GVN into static variables so we don't have to keep passing them around or refetching them.

llvm-svn: 50963

llvm-svn: 50035

llvm-svn: 49842

of calls and less aggressive with non-readnone calls.

llvm-svn: 49516

GVN and into its own pass.

llvm-svn: 49419

llvm-svn: 49418

in both time and memory savings for GVN.  For example, one testcase went from 10.5s to 6s with
this patch.

llvm-svn: 49345

allocations, which GVN can't optimize anyways.

llvm-svn: 49329

Specifically, introduction of XXX::Create methods
for Users that have a potentially variable number of
Uses.

llvm-svn: 49277

when something changes, instead of moving forward.  This allows us to 
simplify memset lowering, inserting the memset at the end of the range of 
stuff we're touching instead of at the start.

This, in turn, allows us to make use of the addressing instructions already
used in the function instead of inserting our own.  For example, we now
codegen:

	%tmp41 = getelementptr [8 x i8]* %ref_idx, i32 0, i32 0		; <i8*> [#uses=2]
	call void @llvm.memset.i64( i8* %tmp41, i8 -1, i64 8, i32 1 )

instead of:

	%tmp20 = getelementptr [8 x i8]* %ref_idx, i32 0, i32 7		; <i8*> [#uses=1]
	%ptroffset = getelementptr i8* %tmp20, i64 -7		; <i8*> [#uses=1]
	call void @llvm.memset.i64( i8* %ptroffset, i8 -1, i64 8, i32 1 )

llvm-svn: 48940

into a memset!) faster by avoiding an allocation of an std::list node.

llvm-svn: 48939

llvm-svn: 48937

memsets that initialize "structs of arrays" and other store sequences
that are not sequential.  This is still only enabled if you pass 
-form-memset-from-stores.  The flag is not heavily tested and I haven't
analyzed the perf regressions when -form-memset-from-stores is passed
either, but this causes no make check regressions.

llvm-svn: 48909

llvm-svn: 48720

This fires dozens of times across spec and multisource, but I don't know
if it actually speeds stuff up.  Hopefully the testers will show something
nice :)

llvm-svn: 48680