summaryrefslogtreecommitdiff
path: root/test/CodeGen/X86/v2f32.ll
Commit message (Collapse)AuthorAge
* Convert CodeGen/*/*.ll tests to use the new CHECK-LABEL for easier ↵Stephen Lin2013-07-13
| | | | | | | | | | | debugging. No functionality change and all tests pass after conversion. This was done with the following sed invocation to catch label lines demarking function boundaries: sed -i '' "s/^;\( *\)\([A-Z0-9_]*\):\( *\)test\([A-Za-z0-9_-]*\):\( *\)$/;\1\2-LABEL:\3test\4:\5/g" test/CodeGen/*/*.ll which was written conservatively to avoid false positives rather than false negatives. I scanned through all the changes and everything looks correct. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186258 91177308-0d34-0410-b5e6-96231b3b80d8
* Attempt to fix -mtriple=i686-{cygwin|mingw|win32} regressions. Nakamura,Bruno Cardoso Lopes2011-09-20
| | | | | | if this doesn't work, please provide more details. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140107 91177308-0d34-0410-b5e6-96231b3b80d8
* test/CodeGen/X86: Add a pattern for Win64.NAKAMURA Takumi2011-03-16
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127733 91177308-0d34-0410-b5e6-96231b3b80d8
* Change handling of illegal vector types to widen when possible instead of Chris Lattner2010-08-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | expanding: e.g. <2 x float> -> <4 x float> instead of -> 2 floats. This affects two places in the code: handling cross block values and handling function return and arguments. Since vectors are already widened by legalizetypes, this gives us much better code and unblocks x86-64 abi and SPU abi work. For example, this (which is a silly example of a cross-block value): define <4 x float> @test2(<4 x float> %A) nounwind { %B = shufflevector <4 x float> %A, <4 x float> undef, <2 x i32> <i32 0, i32 1> %C = fadd <2 x float> %B, %B br label %BB BB: %D = fadd <2 x float> %C, %C %E = shufflevector <2 x float> %D, <2 x float> undef, <4 x i32> <i32 0, i32 1, i32 undef, i32 undef> ret <4 x float> %E } Now compiles into: _test2: ## @test2 ## BB#0: addps %xmm0, %xmm0 addps %xmm0, %xmm0 ret previously it compiled into: _test2: ## @test2 ## BB#0: addps %xmm0, %xmm0 pshufd $1, %xmm0, %xmm1 ## kill: XMM0<def> XMM0<kill> XMM0<def> insertps $0, %xmm0, %xmm0 insertps $16, %xmm1, %xmm0 addps %xmm0, %xmm0 ret This implements rdar://8230384 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112101 91177308-0d34-0410-b5e6-96231b3b80d8
* another v2f32 case, in this case showing poor codegen.Chris Lattner2010-07-05
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107614 91177308-0d34-0410-b5e6-96231b3b80d8
* fix test on non-x86 hosts.Chris Lattner2010-07-05
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107608 91177308-0d34-0410-b5e6-96231b3b80d8
* Just rip v2f32 support completely out of the X86 backend. InChris Lattner2010-07-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* fix PR7518 - terrible codegen of <2 x float>, by only markingChris Lattner2010-07-04
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107600 91177308-0d34-0410-b5e6-96231b3b80d8