llvm-svn: 50106

  br (and X, phi(Y, Z, false)), label L1, label L2

This triggers once on 252.eon and 6 times on 176.gcc.  Blocks 
in question often look like this:

bb262:		; preds = %bb261, %bb248
	%iftmp.251.0 = phi i1 [ true, %bb261 ], [ false, %bb248 ]		; <i1> [#uses=4]
	%tmp270 = icmp eq %struct.rtx_def* %tmp.0.i, null		; <i1> [#uses=1]
	%bothcond = or i1 %iftmp.251.0, %tmp270		; <i1> [#uses=1]
	br i1 %bothcond, label %bb288, label %bb273

In this case, it is clear that it doesn't matter if tmp.0.i is null when coming from bb261.  When coming from bb248, it is all that matters.


Another random example:

check_asm_operands.exit:		; preds = %check_asm_operands.exit.thr_comm, %bb30.i, %bb12.i, %bb6.i413
	%tmp.0.i420 = phi i1 [ true, %bb6.i413 ], [ true, %bb12.i ], [ true, %bb30.i ], [ false, %check_asm_operands.exit.thr_comm ; <i1> [#uses=1]
	call void @llvm.stackrestore( i8* %savedstack ) nounwind 
	%tmp4389 = icmp eq i32 %added_sets_1.0, 0		; <i1> [#uses=1]
	%tmp4394 = icmp eq i32 %added_sets_2.0, 0		; <i1> [#uses=1]
	%bothcond80 = and i1 %tmp4389, %tmp4394		; <i1> [#uses=1]
	%bothcond81 = and i1 %bothcond80, %tmp.0.i420		; <i1> [#uses=1]
	br i1 %bothcond81, label %bb4398, label %bb4397

Here is the case from 252.eon:

bb290.i.i:		; preds = %bb23.i57.i.i, %bb8.i39.i.i, %bb100.i.i, %bb100.i.i, %bb85.i.i110
	%myEOF.1.i.i = phi i1 [ true, %bb100.i.i ], [ true, %bb100.i.i ], [ true, %bb85.i.i110 ], [ true, %bb8.i39.i.i ], [ false, %bb23.i57.i.i ]		; <i1> [#uses=2]
	%i.4.i.i = phi i32 [ %i.1.i.i, %bb85.i.i110 ], [ %i.0.i.i, %bb100.i.i ], [ %i.0.i.i, %bb100.i.i ], [ %i.3.i.i, %bb8.i39.i.i ], [ %i.3.i.i, %bb23.i57.i.i ]		; <i32> [#uses=3]
	%tmp292.i.i = load i8* %tmp16.i.i100, align 1		; <i8> [#uses=1]
	%tmp293.not.i.i = icmp ne i8 %tmp292.i.i, 0		; <i1> [#uses=1]
	%bothcond.i.i = and i1 %tmp293.not.i.i, %myEOF.1.i.i		; <i1> [#uses=1]
	br i1 %bothcond.i.i, label %bb202.i.i, label %bb301.i.i
  Factoring out 3 common predecessors.

On the path from any blocks other than bb23.i57.i.i, the load and compare 
are dead.

llvm-svn: 50096

llvm-svn: 50094

llvm-svn: 50080

getelementptr-seteq.ll into:

define i1 @test(i64 %X, %S* %P) {
	%C = icmp eq i64 %X, -1		; <i1> [#uses=1]
	ret i1 %C
}

instead of:

define i1 @test(i64 %X, %S* %P) {
	%A.idx.mask = and i64 %X, 4611686018427387903		; <i64> [#uses=1]
	%C = icmp eq i64 %A.idx.mask, 4611686018427387903		; <i1> [#uses=1]
	ret i1 %C
}

And fixes the second half of PR2235.  This speeds up the insertion sort
case by 45%, from 1.12s to 0.77s.  In practice, this will significantly
speed up for loops structured like:

for (double *P = Base + N; P != Base; --P)
  ...

Which happens frequently for C++ iterators.

llvm-svn: 50079

llvm-svn: 50047

llvm-svn: 50035

and simplify code that was fallout from the separation of memcpyopt and gvn.

llvm-svn: 50034

llvm-svn: 50022

llvm-svn: 50016

llvm-svn: 50006

a call to Instruction::isUsedOutsideOfBlock.

llvm-svn: 50005

llvm-svn: 50003

Add a cost function.

llvm-svn: 50002

such as those in PR2235.  Right now the pass is not very
effective. :)

llvm-svn: 50000

llvm-svn: 49989

llvm-svn: 49977

llvm-svn: 49842

llvm-svn: 49681

llvm-svn: 49671

llvm-svn: 49657

which is significantly more efficient.

llvm-svn: 49614

of calls and less aggressive with non-readnone calls.

llvm-svn: 49516

in addition to integer expressions. Rewrite GetOrEnforceKnownAlignment
as a ComputeMaskedBits problem, moving all of its special alignment
knowledge to ComputeMaskedBits as low-zero-bits knowledge.

Also, teach ComputeMaskedBits a few basic things about Mul and PHI
instructions.

This improves ComputeMaskedBits-based simplifications in a few cases,
but more noticeably it significantly improves instcombine's alignment
detection for loads, stores, and memory intrinsics.

llvm-svn: 49492

llvm-svn: 49430

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

llvm-svn: 49283

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

llvm-svn: 49277

Iterators folloring a SmallVector erased element are invalidated so
don't access cached iterators from after the erased element.

Re-apply 49056 with SmallVector support.

llvm-svn: 49106

llvm-svn: 49060

Iterators folloring a SmallVector erased element are invalidated so
don't access cached iterators from after the erased element.

llvm-svn: 49056

llvm-svn: 48971

patch by David Chisnall.

llvm-svn: 48963

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