RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-25 12:12:47 +01:00
Code Issues Projects Releases Wiki Activity
28d769100d
llvm-mirror/test/CodeGen/Thumb2/mve-vld4-post.ll

258 lines
11 KiB
LLVM
Raw Normal View History

[ARM] MVE VLDn post inc tests. NFC
2020-01-18 19:15:06 +01:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
[ARM] Replace arm vendor with none. NFC
2020-04-22 17:33:11 +02:00
; RUN: llc -mtriple=thumbv8.1m.main-none-none-eabi -mattr=+mve.fp,+fp64 -mve-max-interleave-factor=4 -verify-machineinstrs %s -o - | FileCheck %s
[ARM] MVE VLDn post inc tests. NFC
2020-01-18 19:15:06 +01:00
; i32
define <16 x i32> *@vld4_v4i32(<16 x i32> *%src, <4 x i32> *%dst) {
; CHECK-LABEL: vld4_v4i32:
; CHECK: @ %bb.0: @ %entry
; CHECK-NEXT: .vsave {d8, d9}
; CHECK-NEXT: vpush {d8, d9}
; CHECK-NEXT: vld40.32 {q0, q1, q2, q3}, [r0]
; CHECK-NEXT: vld41.32 {q0, q1, q2, q3}, [r0]
; CHECK-NEXT: vld42.32 {q0, q1, q2, q3}, [r0]
[ARM] MVE VLDn postinc This adds Post inc variants of the VLD2/4 and VST2/4 instructions in MVE. It uses the same mechanism/nodes as Neon, transforming the intrinsic+add pair into a ARMISD::VLD2_UPD, which gets selected to a post-inc instruction. The code to do that is mostly taken from the existing Neon code, but simplified as less variants are needed. It also fills in some getTgtMemIntrinsic for the arm.mve.vld2/4 instrinsics, which allow the nodes to have MMO's, calculated as the full length to the memory being loaded/stored. Differential Revision: https://reviews.llvm.org/D71194
2020-01-18 19:25:45 +01:00
; CHECK-NEXT: vld43.32 {q0, q1, q2, q3}, [r0]!
[ARM] MVE VLDn post inc tests. NFC
2020-01-18 19:15:06 +01:00
; CHECK-NEXT: @ kill: def $q0 killed $q0 killed $q0_q1_q2_q3
; CHECK-NEXT: vadd.i32 q4, q2, q3
; CHECK-NEXT: vadd.i32 q0, q0, q1
; CHECK-NEXT: vadd.i32 q0, q0, q4
; CHECK-NEXT: vstrw.32 q0, [r1]
; CHECK-NEXT: vpop {d8, d9}
; CHECK-NEXT: bx lr
entry:
%l1 = load <16 x i32>, <16 x i32>* %src, align 4
%s1 = shufflevector <16 x i32> %l1, <16 x i32> undef, <4 x i32> <i32 0, i32 4, i32 8, i32 12>
%s2 = shufflevector <16 x i32> %l1, <16 x i32> undef, <4 x i32> <i32 1, i32 5, i32 9, i32 13>
%s3 = shufflevector <16 x i32> %l1, <16 x i32> undef, <4 x i32> <i32 2, i32 6, i32 10, i32 14>
%s4 = shufflevector <16 x i32> %l1, <16 x i32> undef, <4 x i32> <i32 3, i32 7, i32 11, i32 15>
%a1 = add <4 x i32> %s1, %s2
%a2 = add <4 x i32> %s3, %s4
%a3 = add <4 x i32> %a1, %a2
store <4 x i32> %a3, <4 x i32> *%dst
%ret = getelementptr inbounds <16 x i32>, <16 x i32>* %src, i32 1
ret <16 x i32> *%ret
}
; i16
define <32 x i16> *@vld4_v8i16(<32 x i16> *%src, <8 x i16> *%dst) {
; CHECK-LABEL: vld4_v8i16:
; CHECK: @ %bb.0: @ %entry
; CHECK-NEXT: .vsave {d8, d9}
; CHECK-NEXT: vpush {d8, d9}
; CHECK-NEXT: vld40.16 {q0, q1, q2, q3}, [r0]
; CHECK-NEXT: vld41.16 {q0, q1, q2, q3}, [r0]
; CHECK-NEXT: vld42.16 {q0, q1, q2, q3}, [r0]
[ARM] MVE VLDn postinc This adds Post inc variants of the VLD2/4 and VST2/4 instructions in MVE. It uses the same mechanism/nodes as Neon, transforming the intrinsic+add pair into a ARMISD::VLD2_UPD, which gets selected to a post-inc instruction. The code to do that is mostly taken from the existing Neon code, but simplified as less variants are needed. It also fills in some getTgtMemIntrinsic for the arm.mve.vld2/4 instrinsics, which allow the nodes to have MMO's, calculated as the full length to the memory being loaded/stored. Differential Revision: https://reviews.llvm.org/D71194
2020-01-18 19:25:45 +01:00
; CHECK-NEXT: vld43.16 {q0, q1, q2, q3}, [r0]!
[ARM] MVE VLDn post inc tests. NFC
2020-01-18 19:15:06 +01:00
; CHECK-NEXT: @ kill: def $q0 killed $q0 killed $q0_q1_q2_q3
; CHECK-NEXT: vadd.i16 q4, q2, q3
; CHECK-NEXT: vadd.i16 q0, q0, q1
; CHECK-NEXT: vadd.i16 q0, q0, q4
; CHECK-NEXT: vstrw.32 q0, [r1]
; CHECK-NEXT: vpop {d8, d9}
; CHECK-NEXT: bx lr
entry:
%l1 = load <32 x i16>, <32 x i16>* %src, align 4
%s1 = shufflevector <32 x i16> %l1, <32 x i16> undef, <8 x i32> <i32 0, i32 4, i32 8, i32 12, i32 16, i32 20, i32 24, i32 28>
%s2 = shufflevector <32 x i16> %l1, <32 x i16> undef, <8 x i32> <i32 1, i32 5, i32 9, i32 13, i32 17, i32 21, i32 25, i32 29>
%s3 = shufflevector <32 x i16> %l1, <32 x i16> undef, <8 x i32> <i32 2, i32 6, i32 10, i32 14, i32 18, i32 22, i32 26, i32 30>
%s4 = shufflevector <32 x i16> %l1, <32 x i16> undef, <8 x i32> <i32 3, i32 7, i32 11, i32 15, i32 19, i32 23, i32 27, i32 31>
%a1 = add <8 x i16> %s1, %s2
%a2 = add <8 x i16> %s3, %s4
%a3 = add <8 x i16> %a1, %a2
store <8 x i16> %a3, <8 x i16> *%dst
%ret = getelementptr inbounds <32 x i16>, <32 x i16>* %src, i32 1
ret <32 x i16> *%ret
}
; i8
define <64 x i8> *@vld4_v16i8(<64 x i8> *%src, <16 x i8> *%dst) {
; CHECK-LABEL: vld4_v16i8:
; CHECK: @ %bb.0: @ %entry
; CHECK-NEXT: .vsave {d8, d9}
; CHECK-NEXT: vpush {d8, d9}
; CHECK-NEXT: vld40.8 {q0, q1, q2, q3}, [r0]
; CHECK-NEXT: vld41.8 {q0, q1, q2, q3}, [r0]
; CHECK-NEXT: vld42.8 {q0, q1, q2, q3}, [r0]
[ARM] MVE VLDn postinc This adds Post inc variants of the VLD2/4 and VST2/4 instructions in MVE. It uses the same mechanism/nodes as Neon, transforming the intrinsic+add pair into a ARMISD::VLD2_UPD, which gets selected to a post-inc instruction. The code to do that is mostly taken from the existing Neon code, but simplified as less variants are needed. It also fills in some getTgtMemIntrinsic for the arm.mve.vld2/4 instrinsics, which allow the nodes to have MMO's, calculated as the full length to the memory being loaded/stored. Differential Revision: https://reviews.llvm.org/D71194
2020-01-18 19:25:45 +01:00
; CHECK-NEXT: vld43.8 {q0, q1, q2, q3}, [r0]!
[ARM] MVE VLDn post inc tests. NFC
2020-01-18 19:15:06 +01:00
; CHECK-NEXT: @ kill: def $q0 killed $q0 killed $q0_q1_q2_q3
; CHECK-NEXT: vadd.i8 q4, q2, q3
; CHECK-NEXT: vadd.i8 q0, q0, q1
; CHECK-NEXT: vadd.i8 q0, q0, q4
; CHECK-NEXT: vstrw.32 q0, [r1]
; CHECK-NEXT: vpop {d8, d9}
; CHECK-NEXT: bx lr
entry:
%l1 = load <64 x i8>, <64 x i8>* %src, align 4
%s1 = shufflevector <64 x i8> %l1, <64 x i8> undef, <16 x i32> <i32 0, i32 4, i32 8, i32 12, i32 16, i32 20, i32 24, i32 28, i32 32, i32 36, i32 40, i32 44, i32 48, i32 52, i32 56, i32 60>
%s2 = shufflevector <64 x i8> %l1, <64 x i8> undef, <16 x i32> <i32 1, i32 5, i32 9, i32 13, i32 17, i32 21, i32 25, i32 29, i32 33, i32 37, i32 41, i32 45, i32 49, i32 53, i32 57, i32 61>
%s3 = shufflevector <64 x i8> %l1, <64 x i8> undef, <16 x i32> <i32 2, i32 6, i32 10, i32 14, i32 18, i32 22, i32 26, i32 30, i32 34, i32 38, i32 42, i32 46, i32 50, i32 54, i32 58, i32 62>
%s4 = shufflevector <64 x i8> %l1, <64 x i8> undef, <16 x i32> <i32 3, i32 7, i32 11, i32 15, i32 19, i32 23, i32 27, i32 31, i32 35, i32 39, i32 43, i32 47, i32 51, i32 55, i32 59, i32 63>
%a1 = add <16 x i8> %s1, %s2
%a2 = add <16 x i8> %s3, %s4
%a3 = add <16 x i8> %a1, %a2
store <16 x i8> %a3, <16 x i8> *%dst
%ret = getelementptr inbounds <64 x i8>, <64 x i8>* %src, i32 1
ret <64 x i8> *%ret
}
; i64
define <8 x i64> *@vld4_v2i64(<8 x i64> *%src, <2 x i64> *%dst) {
; CHECK-LABEL: vld4_v2i64:
; CHECK: @ %bb.0: @ %entry
[ARM] Create VMOVRRD from adjacent vector extracts This adds a combine for extract(x, n); extract(x, n+1) -> VMOVRRD(extract x, n/2). This allows two vector lanes to be moved at the same time in a single instruction, and thanks to the other VMOVRRD folds we have added recently can help reduce the amount of executed instructions. Floating point types are very similar, but will include a bitcast to an integer type. This also adds a shouldRewriteCopySrc, to prevent copy propagation from DPR to SPR, which can break as not all DPR regs can be extracted from directly. Otherwise the machine verifier is unhappy. Differential Revision: https://reviews.llvm.org/D100244
2021-04-20 16:15:43 +02:00
; CHECK-NEXT: .save {r4, r5, r6, r7, r8, lr}
; CHECK-NEXT: push.w {r4, r5, r6, r7, r8, lr}
; CHECK-NEXT: .vsave {d8, d9}
; CHECK-NEXT: vpush {d8, d9}
; CHECK-NEXT: vldrw.u32 q0, [r0, #16]
; CHECK-NEXT: vldrw.u32 q2, [r0, #48]
; CHECK-NEXT: vldrw.u32 q4, [r0, #32]
[ARM] Distribute MVE post-increments This adds some extra processing into the Pre-RA ARM load/store optimizer to detect and merge MVE loads/stores and adds of the same base. This we don't always turn into a post-inc during ISel, and due to the nature of it being a graph we don't always know an order to use for the nodes, not knowing which nodes to make post-inc and which to use the new post-inc of. After ISel, we have an order that we can use to post-inc the following instructions. So this looks for a loads/store with a starting offset of 0, and an add/sub from the same base, plus a number of other loads/stores. We then do some checks and convert the zero offset load/store into a postinc variant. Any loads/stores after it have the offset subtracted from their immediates. For example: LDR #4 LDR #4 LDR #0 LDR_POSTINC #16 LDR #8 LDR #-8 LDR #12 LDR #-4 ADD #16 It only handles MVE loads/stores at the moment. Normal loads/store will be added in a followup patch, they just have some extra details to ensure that we keep generating LDRD/LDM successfully. Differential Revision: https://reviews.llvm.org/D77813
2020-04-22 14:30:22 +02:00
; CHECK-NEXT: vmov.f64 d2, d1
[ARM] MVE VLDn post inc tests. NFC
2020-01-18 19:15:06 +01:00
; CHECK-NEXT: vmov.f32 s5, s3
; CHECK-NEXT: vmov.f32 s6, s10
; CHECK-NEXT: vmov.f32 s2, s8
; CHECK-NEXT: vmov.f32 s7, s11
[ARM] Create VMOVRRD from adjacent vector extracts This adds a combine for extract(x, n); extract(x, n+1) -> VMOVRRD(extract x, n/2). This allows two vector lanes to be moved at the same time in a single instruction, and thanks to the other VMOVRRD folds we have added recently can help reduce the amount of executed instructions. Floating point types are very similar, but will include a bitcast to an integer type. This also adds a shouldRewriteCopySrc, to prevent copy propagation from DPR to SPR, which can break as not all DPR regs can be extracted from directly. Otherwise the machine verifier is unhappy. Differential Revision: https://reviews.llvm.org/D100244
2021-04-20 16:15:43 +02:00
; CHECK-NEXT: vmov.f32 s3, s9
; CHECK-NEXT: vldrw.u32 q2, [r0], #64
; CHECK-NEXT: vmov.f64 d6, d5
; CHECK-NEXT: vmov.f32 s13, s11
; CHECK-NEXT: vmov.f32 s14, s18
; CHECK-NEXT: vmov.f32 s10, s16
; CHECK-NEXT: vmov.f32 s15, s19
; CHECK-NEXT: vmov.f32 s11, s17
; CHECK-NEXT: vmov lr, r12, d3
; CHECK-NEXT: vmov r2, r7, d1
; CHECK-NEXT: vmov r4, r8, d7
; CHECK-NEXT: vmov r3, r6, d5
; CHECK-NEXT: adds.w r2, r2, lr
; CHECK-NEXT: adc.w r7, r7, r12
; CHECK-NEXT: adds r3, r3, r4
; CHECK-NEXT: vmov r4, r5, d2
; CHECK-NEXT: adc.w r6, r6, r8
; CHECK-NEXT: adds.w r12, r3, r2
; CHECK-NEXT: vmov r3, r2, d0
; CHECK-NEXT: adc.w lr, r6, r7
; CHECK-NEXT: adds r3, r3, r4
; CHECK-NEXT: vmov r6, r4, d6
; CHECK-NEXT: adcs r2, r5
; CHECK-NEXT: vmov r5, r7, d4
; CHECK-NEXT: adds r5, r5, r6
; CHECK-NEXT: adcs r4, r7
; CHECK-NEXT: adds r3, r3, r5
; CHECK-NEXT: adcs r2, r4
; CHECK-NEXT: vmov q0[2], q0[0], r3, r12
; CHECK-NEXT: vmov q0[3], q0[1], r2, lr
[ARM] MVE VLDn post inc tests. NFC
2020-01-18 19:15:06 +01:00
; CHECK-NEXT: vstrw.32 q0, [r1]
[ARM] Create VMOVRRD from adjacent vector extracts This adds a combine for extract(x, n); extract(x, n+1) -> VMOVRRD(extract x, n/2). This allows two vector lanes to be moved at the same time in a single instruction, and thanks to the other VMOVRRD folds we have added recently can help reduce the amount of executed instructions. Floating point types are very similar, but will include a bitcast to an integer type. This also adds a shouldRewriteCopySrc, to prevent copy propagation from DPR to SPR, which can break as not all DPR regs can be extracted from directly. Otherwise the machine verifier is unhappy. Differential Revision: https://reviews.llvm.org/D100244
2021-04-20 16:15:43 +02:00
; CHECK-NEXT: vpop {d8, d9}
; CHECK-NEXT: pop.w {r4, r5, r6, r7, r8, pc}
[ARM] MVE VLDn post inc tests. NFC
2020-01-18 19:15:06 +01:00
entry:
%l1 = load <8 x i64>, <8 x i64>* %src, align 4
%s1 = shufflevector <8 x i64> %l1, <8 x i64> undef, <2 x i32> <i32 0, i32 4>
%s2 = shufflevector <8 x i64> %l1, <8 x i64> undef, <2 x i32> <i32 1, i32 5>
%s3 = shufflevector <8 x i64> %l1, <8 x i64> undef, <2 x i32> <i32 2, i32 6>
%s4 = shufflevector <8 x i64> %l1, <8 x i64> undef, <2 x i32> <i32 3, i32 7>
%a1 = add <2 x i64> %s1, %s2
%a2 = add <2 x i64> %s3, %s4
%a3 = add <2 x i64> %a1, %a2
store <2 x i64> %a3, <2 x i64> *%dst
%ret = getelementptr inbounds <8 x i64>, <8 x i64>* %src, i32 1
ret <8 x i64> *%ret
}
; f32
define <16 x float> *@vld4_v4f32(<16 x float> *%src, <4 x float> *%dst) {
; CHECK-LABEL: vld4_v4f32:
; CHECK: @ %bb.0: @ %entry
; CHECK-NEXT: .vsave {d8, d9}
; CHECK-NEXT: vpush {d8, d9}
; CHECK-NEXT: vld40.32 {q0, q1, q2, q3}, [r0]
; CHECK-NEXT: vld41.32 {q0, q1, q2, q3}, [r0]
; CHECK-NEXT: vld42.32 {q0, q1, q2, q3}, [r0]
[ARM] MVE VLDn postinc This adds Post inc variants of the VLD2/4 and VST2/4 instructions in MVE. It uses the same mechanism/nodes as Neon, transforming the intrinsic+add pair into a ARMISD::VLD2_UPD, which gets selected to a post-inc instruction. The code to do that is mostly taken from the existing Neon code, but simplified as less variants are needed. It also fills in some getTgtMemIntrinsic for the arm.mve.vld2/4 instrinsics, which allow the nodes to have MMO's, calculated as the full length to the memory being loaded/stored. Differential Revision: https://reviews.llvm.org/D71194
2020-01-18 19:25:45 +01:00
; CHECK-NEXT: vld43.32 {q0, q1, q2, q3}, [r0]!
[ARM] MVE VLDn post inc tests. NFC
2020-01-18 19:15:06 +01:00
; CHECK-NEXT: @ kill: def $q0 killed $q0 killed $q0_q1_q2_q3
; CHECK-NEXT: vadd.f32 q4, q2, q3
; CHECK-NEXT: vadd.f32 q0, q0, q1
; CHECK-NEXT: vadd.f32 q0, q0, q4
; CHECK-NEXT: vstrw.32 q0, [r1]
; CHECK-NEXT: vpop {d8, d9}
; CHECK-NEXT: bx lr
entry:
%l1 = load <16 x float>, <16 x float>* %src, align 4
%s1 = shufflevector <16 x float> %l1, <16 x float> undef, <4 x i32> <i32 0, i32 4, i32 8, i32 12>
%s2 = shufflevector <16 x float> %l1, <16 x float> undef, <4 x i32> <i32 1, i32 5, i32 9, i32 13>
%s3 = shufflevector <16 x float> %l1, <16 x float> undef, <4 x i32> <i32 2, i32 6, i32 10, i32 14>
%s4 = shufflevector <16 x float> %l1, <16 x float> undef, <4 x i32> <i32 3, i32 7, i32 11, i32 15>
%a1 = fadd <4 x float> %s1, %s2
%a2 = fadd <4 x float> %s3, %s4
%a3 = fadd <4 x float> %a1, %a2
store <4 x float> %a3, <4 x float> *%dst
%ret = getelementptr inbounds <16 x float>, <16 x float>* %src, i32 1
ret <16 x float> *%ret
}
; f16
define <32 x half> *@vld4_v8f16(<32 x half> *%src, <8 x half> *%dst) {
; CHECK-LABEL: vld4_v8f16:
; CHECK: @ %bb.0: @ %entry
; CHECK-NEXT: .vsave {d8, d9}
; CHECK-NEXT: vpush {d8, d9}
; CHECK-NEXT: vld40.16 {q0, q1, q2, q3}, [r0]
; CHECK-NEXT: vld41.16 {q0, q1, q2, q3}, [r0]
; CHECK-NEXT: vld42.16 {q0, q1, q2, q3}, [r0]
[ARM] MVE VLDn postinc This adds Post inc variants of the VLD2/4 and VST2/4 instructions in MVE. It uses the same mechanism/nodes as Neon, transforming the intrinsic+add pair into a ARMISD::VLD2_UPD, which gets selected to a post-inc instruction. The code to do that is mostly taken from the existing Neon code, but simplified as less variants are needed. It also fills in some getTgtMemIntrinsic for the arm.mve.vld2/4 instrinsics, which allow the nodes to have MMO's, calculated as the full length to the memory being loaded/stored. Differential Revision: https://reviews.llvm.org/D71194
2020-01-18 19:25:45 +01:00
; CHECK-NEXT: vld43.16 {q0, q1, q2, q3}, [r0]!
[ARM] MVE VLDn post inc tests. NFC
2020-01-18 19:15:06 +01:00
; CHECK-NEXT: @ kill: def $q0 killed $q0 killed $q0_q1_q2_q3
; CHECK-NEXT: vadd.f16 q4, q2, q3
; CHECK-NEXT: vadd.f16 q0, q0, q1
; CHECK-NEXT: vadd.f16 q0, q0, q4
; CHECK-NEXT: vstrw.32 q0, [r1]
; CHECK-NEXT: vpop {d8, d9}
; CHECK-NEXT: bx lr
entry:
%l1 = load <32 x half>, <32 x half>* %src, align 4
%s1 = shufflevector <32 x half> %l1, <32 x half> undef, <8 x i32> <i32 0, i32 4, i32 8, i32 12, i32 16, i32 20, i32 24, i32 28>
%s2 = shufflevector <32 x half> %l1, <32 x half> undef, <8 x i32> <i32 1, i32 5, i32 9, i32 13, i32 17, i32 21, i32 25, i32 29>
%s3 = shufflevector <32 x half> %l1, <32 x half> undef, <8 x i32> <i32 2, i32 6, i32 10, i32 14, i32 18, i32 22, i32 26, i32 30>
%s4 = shufflevector <32 x half> %l1, <32 x half> undef, <8 x i32> <i32 3, i32 7, i32 11, i32 15, i32 19, i32 23, i32 27, i32 31>
%a1 = fadd <8 x half> %s1, %s2
%a2 = fadd <8 x half> %s3, %s4
%a3 = fadd <8 x half> %a1, %a2
store <8 x half> %a3, <8 x half> *%dst
%ret = getelementptr inbounds <32 x half>, <32 x half>* %src, i32 1
ret <32 x half> *%ret
}
; f64
define <8 x double> *@vld4_v2f64(<8 x double> *%src, <2 x double> *%dst) {
; CHECK-LABEL: vld4_v2f64:
; CHECK: @ %bb.0: @ %entry
; CHECK-NEXT: vldrw.u32 q0, [r0, #48]
; CHECK-NEXT: vldrw.u32 q1, [r0, #32]
; CHECK-NEXT: vadd.f64 d0, d0, d1
; CHECK-NEXT: vadd.f64 d1, d2, d3
; CHECK-NEXT: vldrw.u32 q1, [r0, #16]
[ARM] Distribute MVE post-increments This adds some extra processing into the Pre-RA ARM load/store optimizer to detect and merge MVE loads/stores and adds of the same base. This we don't always turn into a post-inc during ISel, and due to the nature of it being a graph we don't always know an order to use for the nodes, not knowing which nodes to make post-inc and which to use the new post-inc of. After ISel, we have an order that we can use to post-inc the following instructions. So this looks for a loads/store with a starting offset of 0, and an add/sub from the same base, plus a number of other loads/stores. We then do some checks and convert the zero offset load/store into a postinc variant. Any loads/stores after it have the offset subtracted from their immediates. For example: LDR #4 LDR #4 LDR #0 LDR_POSTINC #16 LDR #8 LDR #-8 LDR #12 LDR #-4 ADD #16 It only handles MVE loads/stores at the moment. Normal loads/store will be added in a followup patch, they just have some extra details to ensure that we keep generating LDRD/LDM successfully. Differential Revision: https://reviews.llvm.org/D77813
2020-04-22 14:30:22 +02:00
; CHECK-NEXT: vldrw.u32 q2, [r0], #64
[ARM] MVE VLDn post inc tests. NFC
2020-01-18 19:15:06 +01:00
; CHECK-NEXT: vadd.f64 d2, d2, d3
; CHECK-NEXT: vadd.f64 d3, d4, d5
; CHECK-NEXT: vadd.f64 d1, d1, d0
; CHECK-NEXT: vadd.f64 d0, d3, d2
; CHECK-NEXT: vstrw.32 q0, [r1]
; CHECK-NEXT: bx lr
entry:
%l1 = load <8 x double>, <8 x double>* %src, align 4
%s1 = shufflevector <8 x double> %l1, <8 x double> undef, <2 x i32> <i32 0, i32 4>
%s2 = shufflevector <8 x double> %l1, <8 x double> undef, <2 x i32> <i32 1, i32 5>
%s3 = shufflevector <8 x double> %l1, <8 x double> undef, <2 x i32> <i32 2, i32 6>
%s4 = shufflevector <8 x double> %l1, <8 x double> undef, <2 x i32> <i32 3, i32 7>
%a1 = fadd <2 x double> %s1, %s2
%a2 = fadd <2 x double> %s3, %s4
%a3 = fadd <2 x double> %a1, %a2
store <2 x double> %a3, <2 x double> *%dst
%ret = getelementptr inbounds <8 x double>, <8 x double>* %src, i32 1
ret <8 x double> *%ret
}
Reference in New Issue Copy Permalink