Just rip v2f32 support completely out of the X86 backend. In
authorChris Lattner <sabre@nondot.org>
Sun, 4 Jul 2010 23:07:25 +0000 (23:07 +0000)
committerChris Lattner <sabre@nondot.org>
Sun, 4 Jul 2010 23:07:25 +0000 (23:07 +0000)
commitf172ecd964307a09f2412b38688ac71fd3c1b87d
tree1cb4369845ee002bb22d9c72ca33f591881fbd9d
parente35d9842f73cb7273b1d0712183854f5f99fe24f
Just rip v2f32 support completely out of the X86 backend.  In
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107601 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Target/X86/X86ISelLowering.cpp
test/CodeGen/X86/v2f32.ll