git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90217 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90134 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90133 91177308-0d34-0410-b5e6-96231b3b80d8

 * Do not SEGFAULT if tree entryNode() is NULL
 * Print function names in dotty printer

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90130 91177308-0d34-0410-b5e6-96231b3b80d8

llvm-gcc build.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90113 91177308-0d34-0410-b5e6-96231b3b80d8

and reverse nonlocal memdep maps in synch, this should
fix 255.vortex.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90107 91177308-0d34-0410-b5e6-96231b3b80d8

This permits the devirtualization of llvm.org/PR3100#c9 when compiled by clang.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90099 91177308-0d34-0410-b5e6-96231b3b80d8

    LLVM::Transforms/GVN/2009-02-17-LoadPRECrash.ll
    LLVM::Transforms/GVN/2009-06-17-InvalidPRE.ll



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90096 91177308-0d34-0410-b5e6-96231b3b80d8

was being added to the Result vector, but not being put in the
cache.  This means that if the cache was reused wholesale for a
later query that it would be missing this entry and we'd do an
incorrect load elimination.

Unfortunately, it's not really possible to write a useful 
testcase for this, but this unbreaks 255.vortex.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90093 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90085 91177308-0d34-0410-b5e6-96231b3b80d8

PR5574.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90045 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90039 91177308-0d34-0410-b5e6-96231b3b80d8

way that getUnderlyingObject does it. 

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90038 91177308-0d34-0410-b5e6-96231b3b80d8

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.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90037 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90019 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90016 91177308-0d34-0410-b5e6-96231b3b80d8

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.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90013 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90011 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90002 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90001 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90000 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89997 91177308-0d34-0410-b5e6-96231b3b80d8

translation done by memdep, and reenable gep translation 
again.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89992 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89991 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89990 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89985 91177308-0d34-0410-b5e6-96231b3b80d8

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89981 91177308-0d34-0410-b5e6-96231b3b80d8

SimplifyGEPInst method in InstructionSimplify.h.  No functionality change.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89980 91177308-0d34-0410-b5e6-96231b3b80d8

come.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89979 91177308-0d34-0410-b5e6-96231b3b80d8

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89978 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89975 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89959 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89958 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89957 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89956 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89955 91177308-0d34-0410-b5e6-96231b3b80d8

to exercise this though.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89954 91177308-0d34-0410-b5e6-96231b3b80d8

allows us to compile the example in readme.txt into:

LBB1_1:                                                     ## %bb
	movl	4(%rdx,%rax), %ecx
	movl	%ecx, %esi
	imull	(%rdx,%rax), %esi
	imull	%esi, %ecx
	movl	%esi, 8(%rdx,%rax)
	imull	%ecx, %esi
	movl	%ecx, 12(%rdx,%rax)
	movl	%esi, 16(%rdx,%rax)
	imull	%ecx, %esi
	movl	%esi, 20(%rdx,%rax)
	addq	$16, %rax
	cmpq	$4000, %rax
	jne	LBB1_1

instead of:

LBB1_1: 
	movl	(%rdx,%rax), %ecx
	imull	4(%rdx,%rax), %ecx
	movl	%ecx, 8(%rdx,%rax)
	imull	4(%rdx,%rax), %ecx
	movl	%ecx, 12(%rdx,%rax)
	imull	8(%rdx,%rax), %ecx
	movl	%ecx, 16(%rdx,%rax)
	imull	12(%rdx,%rax), %ecx
	movl	%ecx, 20(%rdx,%rax)
	addq	$16, %rax
	cmpq	$4000, %rax
	jne	LBB1_1

GCC (4.2) doesn't seem to be able to eliminate the loads in this 
testcase either, it generates:

L2:
	movl	(%rdx), %eax
	imull	4(%rdx), %eax
	movl	%eax, 8(%rdx)
	imull	4(%rdx), %eax
	movl	%eax, 12(%rdx)
	imull	8(%rdx), %eax
	movl	%eax, 16(%rdx)
	imull	12(%rdx), %eax
	movl	%eax, 20(%rdx)
	addl	$4, %ecx
	addq	$16, %rdx
	cmpl	$1002, %ecx
	jne	L2




git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89952 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89951 91177308-0d34-0410-b5e6-96231b3b80d8

Change the other half of aliasGEP (which handles GEP differencing) to use DecomposeGEPExpression.  This dramatically simplifies and shrinks the code by eliminating the horrible CheckGEPInstructions method, fixes a miscompilation (@test3) and makes the code more aggressive.  In particular, we now handle the @test4 case, which is reduced from the SmallPtrSet constructor.  Missing this caused us to emit a variable length memset instead of a fixed size one.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89922 91177308-0d34-0410-b5e6-96231b3b80d8