maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGen/arm-neon-misc.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

35 lines
1.1 KiB
C
Raw Normal View History

Avoid using i64 types for vld1q_lane/vst1q_lane intrinsics. The backend has to legalize i64 types by splitting them into two 32-bit pieces, which leads to poor quality code. If we produce code for these intrinsics that uses one-element vector types, which can live in Neon vector registers without getting split up, then the generated code is much better. Radar 11998303. llvm-svn: 161879
2012-08-15 01:27:04 +08:00
// REQUIRES: arm-registered-target
// RUN: %clang_cc1 -triple thumbv7-apple-darwin \
// RUN: -target-abi apcs-gnu \
// RUN: -target-cpu cortex-a8 \
// RUN: -mfloat-abi soft \
// RUN: -target-feature +soft-float-abi \
// RUN: -ffreestanding \
// RUN: -emit-llvm -w -o - %s | FileCheck %s
#include <arm_neon.h>
// Radar 11998303: Avoid using i64 types for vld1q_lane and vst1q_lane Neon
// intrinsics with <2 x i64> vectors to avoid poor code for i64 in the backend.
void t1(uint64_t *src, uint8_t *dst) {
// CHECK: @t1
uint64x2_t q = vld1q_u64(src);
[ARM][NEON] Use address space in vld([1234]|[234]lane) and vst([1234]|[234]lane) instructions This is the clang commit associated with llvm r248887. This commit changes the interface of the vld[1234], vld[234]lane, and vst[1234], vst[234]lane ARM neon intrinsics and associates an address space with the pointer that these intrinsics take. This changes, e.g., <2 x i32> @llvm.arm.neon.vld1.v2i32(i8*, i32) to <2 x i32> @llvm.arm.neon.vld1.v2i32.p0i8(i8*, i32) This change ensures that address spaces are fully taken into account in the ARM target during lowering of interleaved loads and stores. Differential Revision: http://reviews.llvm.org/D13127 llvm-svn: 248888
2015-09-30 18:56:56 +08:00
// CHECK: call <2 x i64> @llvm.arm.neon.vld1.v2i64.p0i8
Avoid using i64 types for vld1q_lane/vst1q_lane intrinsics. The backend has to legalize i64 types by splitting them into two 32-bit pieces, which leads to poor quality code. If we produce code for these intrinsics that uses one-element vector types, which can live in Neon vector registers without getting split up, then the generated code is much better. Radar 11998303. llvm-svn: 161879
2012-08-15 01:27:04 +08:00
vst1q_lane_u64(dst, q, 1);
// CHECK: bitcast <16 x i8> %{{.*}} to <2 x i64>
// CHECK: shufflevector <2 x i64>
[ARM][NEON] Use address space in vld([1234]|[234]lane) and vst([1234]|[234]lane) instructions This is the clang commit associated with llvm r248887. This commit changes the interface of the vld[1234], vld[234]lane, and vst[1234], vst[234]lane ARM neon intrinsics and associates an address space with the pointer that these intrinsics take. This changes, e.g., <2 x i32> @llvm.arm.neon.vld1.v2i32(i8*, i32) to <2 x i32> @llvm.arm.neon.vld1.v2i32.p0i8(i8*, i32) This change ensures that address spaces are fully taken into account in the ARM target during lowering of interleaved loads and stores. Differential Revision: http://reviews.llvm.org/D13127 llvm-svn: 248888
2015-09-30 18:56:56 +08:00
// CHECK: call void @llvm.arm.neon.vst1.p0i8.v1i64
Avoid using i64 types for vld1q_lane/vst1q_lane intrinsics. The backend has to legalize i64 types by splitting them into two 32-bit pieces, which leads to poor quality code. If we produce code for these intrinsics that uses one-element vector types, which can live in Neon vector registers without getting split up, then the generated code is much better. Radar 11998303. llvm-svn: 161879
2012-08-15 01:27:04 +08:00
}
void t2(uint64_t *src1, uint8_t *src2, uint64x2_t *dst) {
// CHECK: @t2
uint64x2_t q = vld1q_u64(src1);
[ARM][NEON] Use address space in vld([1234]|[234]lane) and vst([1234]|[234]lane) instructions This is the clang commit associated with llvm r248887. This commit changes the interface of the vld[1234], vld[234]lane, and vst[1234], vst[234]lane ARM neon intrinsics and associates an address space with the pointer that these intrinsics take. This changes, e.g., <2 x i32> @llvm.arm.neon.vld1.v2i32(i8*, i32) to <2 x i32> @llvm.arm.neon.vld1.v2i32.p0i8(i8*, i32) This change ensures that address spaces are fully taken into account in the ARM target during lowering of interleaved loads and stores. Differential Revision: http://reviews.llvm.org/D13127 llvm-svn: 248888
2015-09-30 18:56:56 +08:00
// CHECK: call <2 x i64> @llvm.arm.neon.vld1.v2i64.p0i8
Avoid using i64 types for vld1q_lane/vst1q_lane intrinsics. The backend has to legalize i64 types by splitting them into two 32-bit pieces, which leads to poor quality code. If we produce code for these intrinsics that uses one-element vector types, which can live in Neon vector registers without getting split up, then the generated code is much better. Radar 11998303. llvm-svn: 161879
2012-08-15 01:27:04 +08:00
q = vld1q_lane_u64(src2, q, 0);
// CHECK: shufflevector <2 x i64>
[ARM][NEON] Use address space in vld([1234]|[234]lane) and vst([1234]|[234]lane) instructions This is the clang commit associated with llvm r248887. This commit changes the interface of the vld[1234], vld[234]lane, and vst[1234], vst[234]lane ARM neon intrinsics and associates an address space with the pointer that these intrinsics take. This changes, e.g., <2 x i32> @llvm.arm.neon.vld1.v2i32(i8*, i32) to <2 x i32> @llvm.arm.neon.vld1.v2i32.p0i8(i8*, i32) This change ensures that address spaces are fully taken into account in the ARM target during lowering of interleaved loads and stores. Differential Revision: http://reviews.llvm.org/D13127 llvm-svn: 248888
2015-09-30 18:56:56 +08:00
// CHECK: call <1 x i64> @llvm.arm.neon.vld1.v1i64.p0i8
Avoid using i64 types for vld1q_lane/vst1q_lane intrinsics. The backend has to legalize i64 types by splitting them into two 32-bit pieces, which leads to poor quality code. If we produce code for these intrinsics that uses one-element vector types, which can live in Neon vector registers without getting split up, then the generated code is much better. Radar 11998303. llvm-svn: 161879
2012-08-15 01:27:04 +08:00
// CHECK: shufflevector <1 x i64>
*dst = q;
// CHECK: store <2 x i64>
}