6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-15 20:29:48 +00:00
Code Issues Projects Releases Wiki Activity
5012f1db20
llvm-6502/test/CodeGen/X86/2010-04-23-mmx-movdq2q.ll

101 lines
2.9 KiB
LLVM
Raw Normal View History

Per Chris, fuse four trivial tests using grep (r102199) into one that uses FileCheck. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102216 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-23 22:12:57 +00:00
; RUN: llc < %s -mtriple=x86_64-apple-darwin -mattr=+mmx,+sse2 | FileCheck %s
Massive rewrite of MMX: The x86_mmx type is used for MMX intrinsics, parameters and return values where these use MMX registers, and is also supported in load, store, and bitcast. Only the above operations generate MMX instructions, and optimizations do not operate on or produce MMX intrinsics. MMX-sized vectors <2 x i32> etc. are lowered to XMM or split into smaller pieces. Optimizations may occur on these forms and the result casted back to x86_mmx, provided the result feeds into a previous existing x86_mmx operation. The point of all this is prevent optimizations from introducing MMX operations, which is unsafe due to the EMMS problem. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115243 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 23:57:10 +00:00
; There are no MMX operations here, so we use XMM or i64.
Per Chris, fuse four trivial tests using grep (r102199) into one that uses FileCheck. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102216 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-23 22:12:57 +00:00
Enable element promotion type legalization by deafault. Changed tests which assumed that vectors are legalized by widening them. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142152 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-16 20:31:33 +00:00
; CHECK: ti8
Per Chris, fuse four trivial tests using grep (r102199) into one that uses FileCheck. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102216 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-23 22:12:57 +00:00
define void @ti8(double %a, double %b) nounwind {
entry:
%tmp1 = bitcast double %a to <8 x i8>
%tmp2 = bitcast double %b to <8 x i8>
%tmp3 = add <8 x i8> %tmp1, %tmp2
[SDAG] Introduce a combined set to the DAG combiner which tracks nodes which have successfully round-tripped through the combine phase, and use this to ensure all operands to DAG nodes are visited by the combiner, even if they are only added during the combine phase. This is critical to have the combiner reach nodes that are *introduced* during combining. Previously these would sometimes be visited and sometimes not be visited based on whether they happened to end up on the worklist or not. Now we always run them through the combiner. This fixes quite a few bad codegen test cases lurking in the suite while also being more principled. Among these, the TLS codegeneration is particularly exciting for programs that have this in the critical path like TSan-instrumented binaries (although I think they engineer to use a different TLS that is faster anyways). I've tried to check for compile-time regressions here by running llc over a merged (but not LTO-ed) clang bitcode file and observed at most a 3% slowdown in llc. Given that this is essentially a worst case (none of opt or clang are running at this phase) I think this is tolerable. The actual LTO case should be even less costly, and the cost in normal compilation should be negligible. With this combining logic, it is possible to re-legalize as we combine which is necessary to implement PSHUFB formation on x86 as a post-legalize DAG combine (my ultimate goal). Differential Revision: http://reviews.llvm.org/D4638 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213898 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 22:15:28 +00:00
; CHECK: paddb
Per Chris, fuse four trivial tests using grep (r102199) into one that uses FileCheck. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102216 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-23 22:12:57 +00:00
store <8 x i8> %tmp3, <8 x i8>* null
ret void
}
Enable element promotion type legalization by deafault. Changed tests which assumed that vectors are legalized by widening them. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142152 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-16 20:31:33 +00:00
; CHECK: ti16
Per Chris, fuse four trivial tests using grep (r102199) into one that uses FileCheck. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102216 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-23 22:12:57 +00:00
define void @ti16(double %a, double %b) nounwind {
entry:
%tmp1 = bitcast double %a to <4 x i16>
%tmp2 = bitcast double %b to <4 x i16>
%tmp3 = add <4 x i16> %tmp1, %tmp2
[SDAG] Introduce a combined set to the DAG combiner which tracks nodes which have successfully round-tripped through the combine phase, and use this to ensure all operands to DAG nodes are visited by the combiner, even if they are only added during the combine phase. This is critical to have the combiner reach nodes that are *introduced* during combining. Previously these would sometimes be visited and sometimes not be visited based on whether they happened to end up on the worklist or not. Now we always run them through the combiner. This fixes quite a few bad codegen test cases lurking in the suite while also being more principled. Among these, the TLS codegeneration is particularly exciting for programs that have this in the critical path like TSan-instrumented binaries (although I think they engineer to use a different TLS that is faster anyways). I've tried to check for compile-time regressions here by running llc over a merged (but not LTO-ed) clang bitcode file and observed at most a 3% slowdown in llc. Given that this is essentially a worst case (none of opt or clang are running at this phase) I think this is tolerable. The actual LTO case should be even less costly, and the cost in normal compilation should be negligible. With this combining logic, it is possible to re-legalize as we combine which is necessary to implement PSHUFB formation on x86 as a post-legalize DAG combine (my ultimate goal). Differential Revision: http://reviews.llvm.org/D4638 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213898 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 22:15:28 +00:00
; CHECK: paddw
Per Chris, fuse four trivial tests using grep (r102199) into one that uses FileCheck. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102216 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-23 22:12:57 +00:00
store <4 x i16> %tmp3, <4 x i16>* null
ret void
}
Enable element promotion type legalization by deafault. Changed tests which assumed that vectors are legalized by widening them. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142152 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-16 20:31:33 +00:00
; CHECK: ti32
Per Chris, fuse four trivial tests using grep (r102199) into one that uses FileCheck. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102216 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-23 22:12:57 +00:00
define void @ti32(double %a, double %b) nounwind {
entry:
%tmp1 = bitcast double %a to <2 x i32>
%tmp2 = bitcast double %b to <2 x i32>
%tmp3 = add <2 x i32> %tmp1, %tmp2
[SDAG] Introduce a combined set to the DAG combiner which tracks nodes which have successfully round-tripped through the combine phase, and use this to ensure all operands to DAG nodes are visited by the combiner, even if they are only added during the combine phase. This is critical to have the combiner reach nodes that are *introduced* during combining. Previously these would sometimes be visited and sometimes not be visited based on whether they happened to end up on the worklist or not. Now we always run them through the combiner. This fixes quite a few bad codegen test cases lurking in the suite while also being more principled. Among these, the TLS codegeneration is particularly exciting for programs that have this in the critical path like TSan-instrumented binaries (although I think they engineer to use a different TLS that is faster anyways). I've tried to check for compile-time regressions here by running llc over a merged (but not LTO-ed) clang bitcode file and observed at most a 3% slowdown in llc. Given that this is essentially a worst case (none of opt or clang are running at this phase) I think this is tolerable. The actual LTO case should be even less costly, and the cost in normal compilation should be negligible. With this combining logic, it is possible to re-legalize as we combine which is necessary to implement PSHUFB formation on x86 as a post-legalize DAG combine (my ultimate goal). Differential Revision: http://reviews.llvm.org/D4638 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213898 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 22:15:28 +00:00
; CHECK: paddd
Per Chris, fuse four trivial tests using grep (r102199) into one that uses FileCheck. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102216 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-23 22:12:57 +00:00
store <2 x i32> %tmp3, <2 x i32>* null
ret void
}
Fix one more batch of X86 tests to be register allocation dependent. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128919 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-05 20:20:30 +00:00
; CHECK: ti64
Per Chris, fuse four trivial tests using grep (r102199) into one that uses FileCheck. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102216 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-23 22:12:57 +00:00
define void @ti64(double %a, double %b) nounwind {
entry:
%tmp1 = bitcast double %a to <1 x i64>
%tmp2 = bitcast double %b to <1 x i64>
%tmp3 = add <1 x i64> %tmp1, %tmp2
Fix one more batch of X86 tests to be register allocation dependent. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128919 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-05 20:20:30 +00:00
; CHECK: addq
Per Chris, fuse four trivial tests using grep (r102199) into one that uses FileCheck. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102216 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-23 22:12:57 +00:00
store <1 x i64> %tmp3, <1 x i64>* null
ret void
}
Massive rewrite of MMX: The x86_mmx type is used for MMX intrinsics, parameters and return values where these use MMX registers, and is also supported in load, store, and bitcast. Only the above operations generate MMX instructions, and optimizations do not operate on or produce MMX intrinsics. MMX-sized vectors <2 x i32> etc. are lowered to XMM or split into smaller pieces. Optimizations may occur on these forms and the result casted back to x86_mmx, provided the result feeds into a previous existing x86_mmx operation. The point of all this is prevent optimizations from introducing MMX operations, which is unsafe due to the EMMS problem. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115243 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 23:57:10 +00:00
; MMX intrinsics calls get us MMX instructions.
Fix one more batch of X86 tests to be register allocation dependent. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128919 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-05 20:20:30 +00:00
; CHECK: ti8a
Massive rewrite of MMX: The x86_mmx type is used for MMX intrinsics, parameters and return values where these use MMX registers, and is also supported in load, store, and bitcast. Only the above operations generate MMX instructions, and optimizations do not operate on or produce MMX intrinsics. MMX-sized vectors <2 x i32> etc. are lowered to XMM or split into smaller pieces. Optimizations may occur on these forms and the result casted back to x86_mmx, provided the result feeds into a previous existing x86_mmx operation. The point of all this is prevent optimizations from introducing MMX operations, which is unsafe due to the EMMS problem. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115243 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 23:57:10 +00:00
define void @ti8a(double %a, double %b) nounwind {
entry:
%tmp1 = bitcast double %a to x86_mmx
; CHECK: movdq2q
%tmp2 = bitcast double %b to x86_mmx
; CHECK: movdq2q
%tmp3 = tail call x86_mmx @llvm.x86.mmx.padd.b(x86_mmx %tmp1, x86_mmx %tmp2)
store x86_mmx %tmp3, x86_mmx* null
ret void
}
Enable element promotion type legalization by deafault. Changed tests which assumed that vectors are legalized by widening them. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142152 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-16 20:31:33 +00:00
; CHECK: ti16a
Massive rewrite of MMX: The x86_mmx type is used for MMX intrinsics, parameters and return values where these use MMX registers, and is also supported in load, store, and bitcast. Only the above operations generate MMX instructions, and optimizations do not operate on or produce MMX intrinsics. MMX-sized vectors <2 x i32> etc. are lowered to XMM or split into smaller pieces. Optimizations may occur on these forms and the result casted back to x86_mmx, provided the result feeds into a previous existing x86_mmx operation. The point of all this is prevent optimizations from introducing MMX operations, which is unsafe due to the EMMS problem. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115243 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 23:57:10 +00:00
define void @ti16a(double %a, double %b) nounwind {
entry:
%tmp1 = bitcast double %a to x86_mmx
; CHECK: movdq2q
%tmp2 = bitcast double %b to x86_mmx
; CHECK: movdq2q
%tmp3 = tail call x86_mmx @llvm.x86.mmx.padd.w(x86_mmx %tmp1, x86_mmx %tmp2)
store x86_mmx %tmp3, x86_mmx* null
ret void
}
Enable element promotion type legalization by deafault. Changed tests which assumed that vectors are legalized by widening them. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142152 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-16 20:31:33 +00:00
; CHECK: ti32a
Massive rewrite of MMX: The x86_mmx type is used for MMX intrinsics, parameters and return values where these use MMX registers, and is also supported in load, store, and bitcast. Only the above operations generate MMX instructions, and optimizations do not operate on or produce MMX intrinsics. MMX-sized vectors <2 x i32> etc. are lowered to XMM or split into smaller pieces. Optimizations may occur on these forms and the result casted back to x86_mmx, provided the result feeds into a previous existing x86_mmx operation. The point of all this is prevent optimizations from introducing MMX operations, which is unsafe due to the EMMS problem. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115243 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 23:57:10 +00:00
define void @ti32a(double %a, double %b) nounwind {
entry:
%tmp1 = bitcast double %a to x86_mmx
; CHECK: movdq2q
%tmp2 = bitcast double %b to x86_mmx
; CHECK: movdq2q
%tmp3 = tail call x86_mmx @llvm.x86.mmx.padd.d(x86_mmx %tmp1, x86_mmx %tmp2)
store x86_mmx %tmp3, x86_mmx* null
ret void
}
Enable element promotion type legalization by deafault. Changed tests which assumed that vectors are legalized by widening them. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142152 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-16 20:31:33 +00:00
; CHECK: ti64a
Massive rewrite of MMX: The x86_mmx type is used for MMX intrinsics, parameters and return values where these use MMX registers, and is also supported in load, store, and bitcast. Only the above operations generate MMX instructions, and optimizations do not operate on or produce MMX intrinsics. MMX-sized vectors <2 x i32> etc. are lowered to XMM or split into smaller pieces. Optimizations may occur on these forms and the result casted back to x86_mmx, provided the result feeds into a previous existing x86_mmx operation. The point of all this is prevent optimizations from introducing MMX operations, which is unsafe due to the EMMS problem. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115243 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 23:57:10 +00:00
define void @ti64a(double %a, double %b) nounwind {
entry:
%tmp1 = bitcast double %a to x86_mmx
; CHECK: movdq2q
%tmp2 = bitcast double %b to x86_mmx
; CHECK: movdq2q
%tmp3 = tail call x86_mmx @llvm.x86.mmx.padd.q(x86_mmx %tmp1, x86_mmx %tmp2)
store x86_mmx %tmp3, x86_mmx* null
ret void
}
declare x86_mmx @llvm.x86.mmx.padd.b(x86_mmx, x86_mmx)
declare x86_mmx @llvm.x86.mmx.padd.w(x86_mmx, x86_mmx)
declare x86_mmx @llvm.x86.mmx.padd.d(x86_mmx, x86_mmx)
declare x86_mmx @llvm.x86.mmx.padd.q(x86_mmx, x86_mmx)
Reference in New Issue Copy Permalink