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

llvm-svn: 89955

to exercise this though.

llvm-svn: 89954

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

llvm-svn: 89952

llvm-svn: 89951

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.

llvm-svn: 89922

Generalize DecomposeGEPExpression to exactly handle what Value::getUnderlyingObject does (when TD is around).  This allows us to avoid calling DecomposeGEPExpression unless the ultimate alias check we care about passes, speedup up BasicAA a bit.

llvm-svn: 89920

Implement a new DecomposeGEPExpression method, which decomposes a GEP into a list of scaled offsets.  Use this to eliminate some previous ad-hoc code which was subtly broken (it assumed all Constant*'s were non-zero, but strange constant express could be zero).

llvm-svn: 89915

llvm-svn: 89914

llvm-svn: 89913

llvm-svn: 89912

llvm-svn: 89905

running tail duplication when doing branch folding for if-conversion, and
we also want to be able to run tail duplication earlier to fix some
reg alloc problems.  Move the CanFallThrough function from BranchFolding
to MachineBasicBlock so that it can be shared by TailDuplication.

llvm-svn: 89904

Rollback changes r89516: Added two SubtargetFeatures::AddFeatures methods, which accept a comma-separated string or already parsed command line parameters as input, and some code re-factoring to use these new methods.

llvm-svn: 89893

ProcessImplicitDefs should watch out for invalidated iterator and extra implicit operands on copies.

llvm-svn: 89880

With the testcase for pr3120, the "threaded interpreter" runtime decreases
from 1788 to 1413 with this change.

llvm-svn: 89877

llvm-svn: 89873

llvm-svn: 89866

it is definitely profitable to tail duplicate indirect branches for x86.
This is likely to be true to various degrees for all modern x86 processors.

llvm-svn: 89865

llvm-svn: 89863

llvm-svn: 89850

API change Path::isSpecialFile to Path::isRegularFile, improve semantics in regards to comments from 89765 post review.

llvm-svn: 89848

llvm-svn: 89846

llvm-svn: 89844

using two swc/lwc instead of sdc/ldc.

llvm-svn: 89826

llvm-svn: 89824

unnecessary save/restore.

llvm-svn: 89823

llvm-svn: 89821

llvm-svn: 89819

Make tail duplication of indirect branches much more aggressive (for targets
that indicate that it is profitable), based on further experience with
this transformation.  I compiled 3 large applications with and without
this more aggressive tail duplication and measured minimal changes in code
size.  ("size" on Darwin seems to round the text size up to the nearest
page boundary, so I can only say that any code size increase was less than
one 4k page.) Radar 7421267.

llvm-svn: 89814

This violates the ABI (that area is "reserved"), and
while it is safe if all code is generated with current
compilers, there is some very old code around that uses
that slot for something else, and breaks if it is stored
into.  Adjust testcases looking for current behavior.
I've verified that the stack frame size is right in all
testcases, whether it changed or not.  7311323.

llvm-svn: 89811

llvm-svn: 89803

llvm-svn: 89793

llvm-svn: 89790

llvm-svn: 89787

llvm-svn: 89786