llvm-svn: 90046

PR5574.

llvm-svn: 90045

handle cases like this:
void test(int N, double* G) {
  long j;
  for (j = 1; j < N - 1; j++)
      G[j+1] = G[j] + G[j+1];
}

where G[1] isn't live into the loop.

llvm-svn: 90041

inserted instructions.  No functionality change until someone starts using it.

llvm-svn: 90039

way that getUnderlyingObject does it. 

This fixes the 'DecomposeGEPExpression and getUnderlyingObject disagree!' 
assertion on sqlite3.

llvm-svn: 90038

if we don't have an address expression available in a predecessor,
then model this as the value being clobbered at the end of the pred
block instead of being modeled as a complete phi translation failure.
This is important for PRE of loads because we want to see that the
load is available in all but this predecessor, and complete phi
translation failure results in not getting any information about
predecessors.

This doesn't do anything until I renable code insertion since PRE
now sees that it is available in all but one predecessors, but can't
insert the addressing in the predecessor that is missing it to 
eliminate the redundancy.

llvm-svn: 90037

to inform GVN about the newly inserted values.  This fixes 
PR5631.

llvm-svn: 90022

fixes PR5630 and sets the stage for the next phase of goodness (testcase
pending).

llvm-svn: 90019

llvm-svn: 90016

for pointing this out.

llvm-svn: 90015

translation of add with immediate.  This allows us
to optimize this function:

void test(int N, double* G) {
  long j;
  G[1] = 1;
    for (j = 1; j < N - 1; j++)
        G[j+1] = G[j] + G[j+1];
}

to only do one load every iteration of the loop.

llvm-svn: 90013

llvm-svn: 90011

llvm-svn: 90009

the FIXME I added yesterday to be implemented.

llvm-svn: 90008

array indexes.  The "complex" case of SRoA still handles them, and correctly.

This fixes a weirdness where we'd correctly avoid transforming A[0][42] if
the 42 was too large, but we'd only do it if it was one gep, not two separate
ones.

llvm-svn: 90007

llvm-svn: 90002

llvm-svn: 90001

fixes a crash analyzing consumer-lame, which had an "%X = add %X, 1"
in unreachable code.

llvm-svn: 90000

where it is not available.  It's unclear how to get this inserted 
computation into GVN's scalar availability sets, Owen, help? :)

llvm-svn: 89997

translation done by memdep, and reenable gep translation 
again.

llvm-svn: 89992

llvm-svn: 89991

llvm-svn: 89990

llvm-svn: 89985

llvm-svn: 89982

This allows us to compile the example from PR5313 into:

LBB1_2:                                                     ## %bb
	incl	%ecx
	movb	%al, (%rsi)
	movslq	%ecx, %rax
	movb	(%rdi,%rax), %al
	testb	%al, %al
	jne	LBB1_2

instead of:

LBB1_2:                                                     ## %bb
	movslq	%eax, %rcx
	incl	%eax
	movb	(%rdi,%rcx), %cl
	movb	%cl, (%rsi)
	movslq	%eax, %rcx
	cmpb	$0, (%rdi,%rcx)
	jne	LBB1_2

llvm-svn: 89981

SimplifyGEPInst method in InstructionSimplify.h.  No functionality change.

llvm-svn: 89980

come.

llvm-svn: 89979

the example in GCC PR16799 to:

LBB1_2:                                                     ## %bb1
	movl	%eax, %eax
	subq	%rax, %rdi
	movq	%rdi, (%rcx)
	movl	(%rdi), %eax
	testl	%eax, %eax
	je	LBB1_2

instead of:

LBB1_2:                                                     ## %bb1
	movl	(%rdi), %ecx
	subq	%rcx, %rdi
	movq	%rdi, (%rax)
	cmpl	$0, (%rdi)
	je	LBB1_2

llvm-svn: 89978

llvm-svn: 89976

llvm-svn: 89975

llvm-svn: 89974

remove in LLVM 3.0

llvm-svn: 89973

llvm-svn: 89972

generates store to undef and some generates store to null as the idiom
for undefined behavior.  Since simplifycfg zaps both, don't remove the
undefined behavior in instcombine.

llvm-svn: 89971

by Alastair Lynn.

llvm-svn: 89970

llvm-svn: 89968

previously already handled it at -m32 because there were no i32->i64 
extensions for addressing.

llvm-svn: 89959

llvm-svn: 89958

llvm-svn: 89957

llvm-svn: 89956