llvm-svn: 107701

the block before calling the expansion hook. And don't
put EFLAGS in a mbb's live-in list twice.

llvm-svn: 107691

llvm-svn: 107678

if profitable.

llvm-svn: 107673

llvm-svn: 107668

from getPhysicalRegisterRegClass.

llvm-svn: 107660

the pseudo instruction is not at the end of the block.

llvm-svn: 107655

registers.  Split out testcases per architecture and os
now.

Patch from Nelson Elhage.

llvm-svn: 107640

llvm-svn: 107625

llvm-svn: 107622

llvm-svn: 107615

llvm-svn: 107613

llvm-svn: 107610

v2f32 is illegal on x86.

llvm-svn: 107609

the example in the testcase, we now generate:

_test1:                                 ## @test1
	movss	4(%esp), %xmm0
	addss	8(%esp), %xmm0
	movl	12(%esp), %eax
	movss	%xmm0, (%eax)
	ret

instead of:

_test1:                                                     ## @test1
	subl	$20, %esp
	movl	24(%esp), %eax
	movq	%mm0, (%esp)
	movq	%mm0, 8(%esp)
	movss	(%esp), %xmm0
	addss	12(%esp), %xmm0
	movss	%xmm0, (%eax)
	addl	$20, %esp
	ret

v2f32 support did not work reliably because most of the X86
backend didn't know it was legal.  It was apparently only added
to support returning source-level v2f32 values in MMX registers
in x86-32 mode.  If ABI compatibility is important on this
GCC-extended-vector type for some reason, then the frontend
should generate IR that returns v2i32 instead of v2f32.  However,
we generally don't try very hard to be abi compatible on gcc
extended vectors. 

llvm-svn: 107601

v2f32 as legal in 32-bit mode.  It is just as terrible there,
but I just care about x86-64 and noone claims it is valuable
in 64-bit mode.

llvm-svn: 107600

llvm-svn: 107599

llvm-svn: 107585

(SDNPMemOperand). This way when they're morphed the memory operands will be
copied as well.

llvm-svn: 107583

llvm-svn: 107569

llvm-svn: 107565

llvm-svn: 107560

llvm-svn: 107558

llvm-svn: 107552

Remove isSS argument from CreateFixedObject. Fixed objects cannot be spill slots so it's always false.

llvm-svn: 107550

llvm-svn: 107549

llvm-svn: 107540

- Fix VEX prefix to be emitted with 3 bytes whenever VEX_5M
represents a REX equivalent two byte leading opcode

llvm-svn: 107523

llvm-svn: 107513

- X86 unfolding should check if the instructions being unfolded has memoperands.
  If there is no memoperands, then it must assume conservative alignment. If this
  would introduce an expensive sse unaligned load / store, then unfoldMemoryOperand
  etc. should not unfold the instruction.

llvm-svn: 107509

llvm-svn: 107500

llvm-svn: 107498

that it checks the immediate values, not just the instructions opcodes.
Radar 8110263.

llvm-svn: 107487

llvm-svn: 107482

llvm-svn: 107448

llvm-svn: 107438

getFunctionAlignment and the corresponding use of that value in the ARM
asm printer, but now we're using the standard asm printer.  The result of
this was that function alignments were dropped completely for Thumb functions.
Radar 8143571.

llvm-svn: 107435

Objective-C metadata types which should be marked as "weak", but which the
linker will remove upon final linkage. However, this linkage isn't specific to
Objective-C.

For example, the "objc_msgSend_fixup_alloc" symbol is defined like this:

      .globl l_objc_msgSend_fixup_alloc
      .weak_definition l_objc_msgSend_fixup_alloc
      .section __DATA, __objc_msgrefs, coalesced
      .align 3
l_objc_msgSend_fixup_alloc:
       .quad   _objc_msgSend_fixup
       .quad   L_OBJC_METH_VAR_NAME_1

This is different from the "linker_private" linkage type, because it can't have
the metadata defined with ".weak_definition".

Currently only supported on Darwin platforms.

llvm-svn: 107433

Add AVX SSE3 packed horizontal and & sub instructions

llvm-svn: 107405

llvm-svn: 107404