llvm-svn: 90419

both source operands.  In the canonical form, the 2nd operand is changed to an
undef and the shuffle mask is adjusted to only reference elements from the 1st
operand.  Radar 7434842.

llvm-svn: 90417

llvm-svn: 90383

function, converting "dyn_cast" to "cast", asserting the correct things, and
other general cleanups.

llvm-svn: 90371

llvm-svn: 90370

llvm-svn: 90366

Patch by Howard Hinnant!

llvm-svn: 90365

that it doesn't have dangling pointers when abstract types are resolved. This
modifies it somewhat to address comments: making the "StructLayoutMap" an
anonymous structure, calling "removeAbstractTypeUser" when appropriate, and
adding asserts where helpful.

llvm-svn: 90362

No functionality change.

llvm-svn: 90336

llvm-svn: 90246

llvm-svn: 90243

For VMOVv*i[16,32], op bit is don't care, and some cmode bits vary depending on
the immediate values.

Ref: Table A7-15 Modified immediate values for Advanced SIMD instructions.
llvm-svn: 90173

llvm-svn: 90166

llvm-svn: 90165

for all the processors where I have tried it, and even when it might not help
performance, the cost is quite low.  The opportunities for duplicating
indirect branches are limited by other factors so code size does not change
much due to tail duplicating indirect branches aggressively.

llvm-svn: 90144

llvm-svn: 90141

divide/remainder since these operations can trap by unroll them and adding undefs
for the resulting vector.

llvm-svn: 90108

llvm-svn: 90050

llvm-svn: 90009

the FIXME I added yesterday to be implemented.

llvm-svn: 90008

llvm-svn: 89982

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

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

llvm-svn: 89913

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

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

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