llvm-svn: 90691

that I'm working on.  This is manifesting as a miscompile of 255.vortex
on some targets.  No check lines yet because it fails.

llvm-svn: 90520

llvm-svn: 90408

llvm-svn: 90380

per Chris' comments.  Adjust testcases to match.

llvm-svn: 90304

llvm-svn: 90216

llvm-svn: 90212

llvm-svn: 90112

llvm-svn: 90049

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

which we now compile to one load in the loop:

LBB1_2:                                                     ## %bb
	movsd	16(%rsi,%rax,8), %xmm2
	incq	%rdx
	addsd	%xmm2, %xmm1
	addsd	%xmm1, %xmm0
	movapd	%xmm2, %xmm1
	movsd	%xmm0, 8(%rsi,%rax,8)
	incq	%rax
	cmpq	%rcx, %rax
	jne	LBB1_2

instead of:

LBB1_2:                                                     ## %bb
	movsd	8(%rsi,%rax,8), %xmm0
	addsd	16(%rsi,%rax,8), %xmm0
	addsd	(%rsi,%rax,8), %xmm0
	movsd	%xmm0, 8(%rsi,%rax,8)
	incq	%rax
	cmpq	%rcx, %rax
	jne	LBB1_2

llvm-svn: 90048

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

llvm-svn: 90047

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

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

llvm-svn: 90022

llvm-svn: 90014

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

add two simple test cases we now optimize (to one load in the loop each) and one we don't (corresponding to the fixme I added yesterday).

llvm-svn: 90012

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

llvm-svn: 89996

llvm-svn: 89995

llvm-svn: 89994

llvm-svn: 89993

translation done by memdep, and reenable gep translation 
again.

llvm-svn: 89992

llvm-svn: 89991

llvm-svn: 89990

llvm-svn: 89985

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

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: 89977

on ppc buildbot.

llvm-svn: 89452

if it is not ultimately captured. Teach BasicAliasAnalysis that a 
local object address which does not escape and is never stored does
not alias with a value resulting from a load.

llvm-svn: 89398

GVN to be more aggressive. Patch by Hans Wennborg! (with a comment added by me)

llvm-svn: 86582

purposes for GVN/DSE.

llvm-svn: 85383

to depend on Ref and ModRef calls within the invariant region.

llvm-svn: 85380

purely local for now.

llvm-svn: 85378

themselves are not marked readonly, but only the called
functions.

llvm-svn: 84253

Memory dependence analysis was incorrectly stopping to scan for stores to a pointer at bitcast uses of a malloc call.
It should continue scanning until the malloc call, and this patch fixes that.

llvm-svn: 83931

from GVN, this also speeds it up, inserts fewer PHI nodes (see the
testcase) and allows it to remove more loads (due to fewer PHI nodes
standing in the way).

llvm-svn: 83746

arrays and structs, which cannot be bitcast to integers.

llvm-svn: 82460

This doesn't kick in too much because of phi translation issues,
but this can be resolved in the future.

llvm-svn: 82447