r48047 r48084 r48085 r48086 r48088 r48096 r48099 r48109 and r48123.

llvm-svn: 50265

ConstantExpression GEPs pointing into constant globals.

llvm-svn: 50256

goes back to the block, e.g.:

  Threading edge through bool from 'bb37.us.thread3829' to 'bb37.us' with cost: 1, across block:

bb37.us:		; preds = %bb37.us.thread3829, %bb37.us, %bb33
	%D1361.1.us = phi i32 [ %tmp36, %bb33 ], [ %D1361.1.us, %bb37.us ], [ 0, %bb37.us.thread3829 ]		; <i32> [#uses=2]
	%tmp39.us = icmp eq i32 %D1361.1.us, 0		; <i1> [#uses=1]
	br i1 %tmp39.us, label %bb37.us, label %bb42.us

llvm-svn: 50251

llvm-svn: 50222

llvm-svn: 50203

sccp tracks getresult values, not call values in this
case.

llvm-svn: 50202

llvm-svn: 50201

Fix said code to handle merging return instructions together correctly
when handling multiple return values.

llvm-svn: 50199

llvm-svn: 50179

llvm-svn: 50174

callees.

llvm-svn: 50142

fix read after free bug (PR2238).

llvm-svn: 50141

would turn every getresult instruction into undef.  This helps with
rdar://5778210

llvm-svn: 50140

type of a different size.

llvm-svn: 50121

Don't do: "(X & 4) >> 1 == 2  --> (X & 4) == 4" if there are more than one uses of the shift result.

llvm-svn: 50118

where a comparison has a phi input and that phi is a constant.  For example,
stuff like:

  Threading edge through bool from 'bb2149' to 'bb2231' with cost: 1, across block:
bb2237:		; preds = %bb2231, %bb2149
	%tmp2328.rle = phi i32 [ %tmp2232, %bb2231 ], [ %tmp2232439, %bb2149 ]		; <i32> [#uses=2]
	%done.0 = phi i32 [ %done.2, %bb2231 ], [ 0, %bb2149 ]		; <i32> [#uses=1]
	%tmp2239 = icmp eq i32 %done.0, 0		; <i1> [#uses=1]
	br i1 %tmp2239, label %bb2231, label %bb2327

or

bb38.i298:		; preds = %bb33.i295, %bb1693
	%tmp39.i296.rle = phi %struct.ibox* [ null, %bb1693 ], [ %tmp39.i296.rle1109, %bb33.i295 ]		; <%struct.ibox*> [#uses=2]
	%minspan.1.i291.reg2mem.1 = phi i32 [ 32000, %bb1693 ], [ %minspan.0.i288, %bb33.i295 ]		; <i32> [#uses=1]
	%tmp40.i297 = icmp eq %struct.ibox* %tmp39.i296.rle, null		; <i1> [#uses=1]
	br i1 %tmp40.i297, label %implfeeds.exit311, label %bb43.i301

This triggers thousands of times in spec.

llvm-svn: 50110

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

fixes a crash in opt on 433.milc.

llvm-svn: 50023

llvm-svn: 50022

as a global helper function.  At the same type, switch it from taking
a vector of predecessors to an arbitrary sequential input.  This allows
us to switch LoopSimplify to use a SmallVector for various temporary
vectors that it passed into SplitBlockPredecessors.

llvm-svn: 50020

nodes, removing a hack.

llvm-svn: 50019

instead of doing it after every call.

llvm-svn: 50018

llvm-svn: 50016

llvm-svn: 50015

llvm-svn: 50014

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

of elements.  Patch by Matthijs Kooijman!

llvm-svn: 49962