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

llvm-svn: 48679

merging optimization.  Nothing to see here, hopefully more later :)

llvm-svn: 48670

llvm-svn: 48662

each basic block.

llvm-svn: 48660

llvm-svn: 48658

pointer bitcast when performing return slot optimization.

llvm-svn: 48343

Improve the return slot optimization to be both more aggressive (not limited to sret parameters), and 
safer (when the passed pointer might be invalid).  Thanks to Duncan and Chris for the idea behind this, 
and extra thanks to Duncan for helping me work out the trap-safety.

llvm-svn: 48280

in an invalid transformation.

llvm-svn: 47639

not safe.  This is fixed by more aggressively checking that the return slot is
not used elsewhere in the function.

llvm-svn: 47544

Fix an issue where GVN would try to use an instruction before its definition when performing return slot optimization.

llvm-svn: 47541

llvm-svn: 47371

llvm-svn: 47364

Refactor this method a bit, and correct a test that was completely wrong but happened to work out anyways. :-)

llvm-svn: 47321

llvm-svn: 47320

llvm-svn: 47319

llvm-svn: 47318

and add some others that should have been in from the first place.  Document the whole thing better.

llvm-svn: 47315

At some point in the future, this check will become smarter.

llvm-svn: 47310

over all the parameters of the callee looking for it.

llvm-svn: 47309

to apply to a memcpy into processInstruction.  Also, fix a bug in the check due to
missing braces.

llvm-svn: 47307

Fix Transforms/GVN/memcpy.ll, which Chris broke in r47275 by reordering the branches.  memcpy's are a kind of CallInst.

llvm-svn: 47305

llvm-svn: 47275

Add support to GVN for performing sret return slot optimization.  This means that, if an sret function tail calls
another sret function, it should pass its own sret parameter to the tail callee, allowing it to fill in the correct
return value.  llvm-gcc does not emit this by default.  Instead, it allocates space in the caller for the sret of
the tail call and then uses memcpy to copy the result into the caller's sret parameter.  This optimization detects
and optimizes that case.

llvm-svn: 47265

llvm-svn: 47111

bugs fixed.  This now passes PPC bootstrap.

llvm-svn: 47026

checks for a malloc/alloca immediately followed by a load.

llvm-svn: 47006

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080128/057882.html

This is causing a miscompilation on PPC G5 and just now seeing it on iMac x86-64.

llvm-svn: 46822

llvm-svn: 46693