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-mve-intrinsics/cplusplus.cpp

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

165 lines
6.4 KiB
C++
Raw Normal View History

[ARM,MVE] Make the MVE intrinsics work in C++! Summary: Apparently nobody has tried this in months of development. It turns out that `FunctionDecl::getBuiltinID` will never consider a function to be a builtin if it is in C++ and not extern "C". So none of the function declarations in <arm_mve.h> are recognized as builtins when clang is compiling in C++ mode: it just emits calls to them as ordinary functions, which then turn out not to exist at link time. The trivial fix is to wrap most of arm_mve.h in an extern "C". Added a test in clang/test/CodeGen/arm-mve-intrinsics which checks basic functioning of the MVE header file in C++ mode. I've filled it with copies of existing test functions from other files in that directory, including a few moderately tricky cases of overloading (in particular one that relies on the strict-polymorphism attribute added in D72518). (I considered making //every// test in that directory compile in both C and C++ mode and check the code generation was identical. But I think that would increase testing time by more than the value it adds, and also update_cc_test_checks gets confused when the output function name varies between RUN lines.) Reviewers: LukeGeeson, MarkMurrayARM, miyuki, dmgreen Reviewed By: MarkMurrayARM Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73268
2020-01-23 22:10:24 +08:00
// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
[CodeGen] fix test to be (mostly) independent of LLVM optimizer; NFC This test would break with the proposed change to IR canonicalization in D79171. The test tried to do the right thing by only using -mem2reg with opt, but it was using -O3 before that step, so the opt part was meaningless.
2020-05-10 23:25:37 +08:00
// RUN: %clang_cc1 -triple thumbv8.1m.main-none-none-eabi -target-feature +mve.fp -mfloat-abi hard -fallow-half-arguments-and-returns -disable-O0-optnone -S -emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
// RUN: %clang_cc1 -triple thumbv8.1m.main-none-none-eabi -target-feature +mve.fp -mfloat-abi hard -fallow-half-arguments-and-returns -disable-O0-optnone -DPOLYMORPHIC -S -emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
[ARM,MVE] Make the MVE intrinsics work in C++! Summary: Apparently nobody has tried this in months of development. It turns out that `FunctionDecl::getBuiltinID` will never consider a function to be a builtin if it is in C++ and not extern "C". So none of the function declarations in <arm_mve.h> are recognized as builtins when clang is compiling in C++ mode: it just emits calls to them as ordinary functions, which then turn out not to exist at link time. The trivial fix is to wrap most of arm_mve.h in an extern "C". Added a test in clang/test/CodeGen/arm-mve-intrinsics which checks basic functioning of the MVE header file in C++ mode. I've filled it with copies of existing test functions from other files in that directory, including a few moderately tricky cases of overloading (in particular one that relies on the strict-polymorphism attribute added in D72518). (I considered making //every// test in that directory compile in both C and C++ mode and check the code generation was identical. But I think that would increase testing time by more than the value it adds, and also update_cc_test_checks gets confused when the output function name varies between RUN lines.) Reviewers: LukeGeeson, MarkMurrayARM, miyuki, dmgreen Reviewed By: MarkMurrayARM Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73268
2020-01-23 22:10:24 +08:00
#include <arm_mve.h>
// CHECK-LABEL: @_Z16test_vbicq_n_s1617__simd128_int16_t(
// CHECK-NEXT: entry:
// CHECK-NEXT: [[TMP0:%.*]] = and <8 x i16> [[A:%.*]], <i16 11007, i16 11007, i16 11007, i16 11007, i16 11007, i16 11007, i16 11007, i16 11007>
// CHECK-NEXT: ret <8 x i16> [[TMP0]]
//
int16x8_t test_vbicq_n_s16(int16x8_t a)
{
#ifdef POLYMORPHIC
return vbicq(a, 0xd500);
#else /* POLYMORPHIC */
return vbicq_n_s16(a, 0xd500);
#endif /* POLYMORPHIC */
}
// CHECK-LABEL: @_Z16test_vbicq_n_u3218__simd128_uint32_t(
// CHECK-NEXT: entry:
// CHECK-NEXT: [[TMP0:%.*]] = and <4 x i32> [[A:%.*]], <i32 -8193, i32 -8193, i32 -8193, i32 -8193>
// CHECK-NEXT: ret <4 x i32> [[TMP0]]
//
uint32x4_t test_vbicq_n_u32(uint32x4_t a)
{
#ifdef POLYMORPHIC
return vbicq(a, 0x2000);
#else /* POLYMORPHIC */
return vbicq_n_u32(a, 0x2000);
#endif /* POLYMORPHIC */
}
// CHECK-LABEL: @_Z16test_vorrq_n_s3217__simd128_int32_t(
// CHECK-NEXT: entry:
// CHECK-NEXT: [[TMP0:%.*]] = or <4 x i32> [[A:%.*]], <i32 65536, i32 65536, i32 65536, i32 65536>
// CHECK-NEXT: ret <4 x i32> [[TMP0]]
//
int32x4_t test_vorrq_n_s32(int32x4_t a)
{
#ifdef POLYMORPHIC
return vorrq(a, 0x10000);
#else /* POLYMORPHIC */
return vorrq_n_s32(a, 0x10000);
#endif /* POLYMORPHIC */
}
// CHECK-LABEL: @_Z16test_vorrq_n_u1618__simd128_uint16_t(
// CHECK-NEXT: entry:
// CHECK-NEXT: [[TMP0:%.*]] = or <8 x i16> [[A:%.*]], <i16 -4096, i16 -4096, i16 -4096, i16 -4096, i16 -4096, i16 -4096, i16 -4096, i16 -4096>
// CHECK-NEXT: ret <8 x i16> [[TMP0]]
//
uint16x8_t test_vorrq_n_u16(uint16x8_t a)
{
#ifdef POLYMORPHIC
return vorrq(a, 0xf000);
#else /* POLYMORPHIC */
return vorrq_n_u16(a, 0xf000);
#endif /* POLYMORPHIC */
}
// CHECK-LABEL: @_Z16test_vcmpeqq_f1619__simd128_float16_tS_(
// CHECK-NEXT: entry:
// CHECK-NEXT: [[TMP0:%.*]] = fcmp oeq <8 x half> [[A:%.*]], [[B:%.*]]
[CodeGen] fix test to be (mostly) independent of LLVM optimizer; NFC This test would break with the proposed change to IR canonicalization in D79171. The test tried to do the right thing by only using -mem2reg with opt, but it was using -O3 before that step, so the opt part was meaningless.
2020-05-10 23:25:37 +08:00
// CHECK-NEXT: [[TMP1:%.*]] = call i32 @llvm.arm.mve.pred.v2i.v8i1(<8 x i1> [[TMP0]])
[ARM,MVE] Make the MVE intrinsics work in C++! Summary: Apparently nobody has tried this in months of development. It turns out that `FunctionDecl::getBuiltinID` will never consider a function to be a builtin if it is in C++ and not extern "C". So none of the function declarations in <arm_mve.h> are recognized as builtins when clang is compiling in C++ mode: it just emits calls to them as ordinary functions, which then turn out not to exist at link time. The trivial fix is to wrap most of arm_mve.h in an extern "C". Added a test in clang/test/CodeGen/arm-mve-intrinsics which checks basic functioning of the MVE header file in C++ mode. I've filled it with copies of existing test functions from other files in that directory, including a few moderately tricky cases of overloading (in particular one that relies on the strict-polymorphism attribute added in D72518). (I considered making //every// test in that directory compile in both C and C++ mode and check the code generation was identical. But I think that would increase testing time by more than the value it adds, and also update_cc_test_checks gets confused when the output function name varies between RUN lines.) Reviewers: LukeGeeson, MarkMurrayARM, miyuki, dmgreen Reviewed By: MarkMurrayARM Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73268
2020-01-23 22:10:24 +08:00
// CHECK-NEXT: [[TMP2:%.*]] = trunc i32 [[TMP1]] to i16
// CHECK-NEXT: ret i16 [[TMP2]]
//
mve_pred16_t test_vcmpeqq_f16(float16x8_t a, float16x8_t b)
{
#ifdef POLYMORPHIC
return vcmpeqq(a, b);
#else /* POLYMORPHIC */
return vcmpeqq_f16(a, b);
#endif /* POLYMORPHIC */
}
// CHECK-LABEL: @_Z18test_vcmpeqq_n_f1619__simd128_float16_tDh(
// CHECK-NEXT: entry:
[CodeGen] fix test to be (mostly) independent of LLVM optimizer; NFC This test would break with the proposed change to IR canonicalization in D79171. The test tried to do the right thing by only using -mem2reg with opt, but it was using -O3 before that step, so the opt part was meaningless.
2020-05-10 23:25:37 +08:00
// CHECK-NEXT: [[B:%.*]] = alloca half, align 2
// CHECK-NEXT: [[TMP:%.*]] = alloca float, align 4
// CHECK-NEXT: store float [[B_COERCE:%.*]], float* [[TMP]], align 4
// CHECK-NEXT: [[TMP0:%.*]] = bitcast half* [[B]] to i8*
// CHECK-NEXT: [[TMP1:%.*]] = bitcast float* [[TMP]] to i8*
// CHECK-NEXT: call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 2 [[TMP0]], i8* align 4 [[TMP1]], i32 2, i1 false)
// CHECK-NEXT: [[B1:%.*]] = load half, half* [[B]], align 2
// CHECK-NEXT: [[DOTSPLATINSERT:%.*]] = insertelement <8 x half> undef, half [[B1]], i32 0
[ARM,MVE] Make the MVE intrinsics work in C++! Summary: Apparently nobody has tried this in months of development. It turns out that `FunctionDecl::getBuiltinID` will never consider a function to be a builtin if it is in C++ and not extern "C". So none of the function declarations in <arm_mve.h> are recognized as builtins when clang is compiling in C++ mode: it just emits calls to them as ordinary functions, which then turn out not to exist at link time. The trivial fix is to wrap most of arm_mve.h in an extern "C". Added a test in clang/test/CodeGen/arm-mve-intrinsics which checks basic functioning of the MVE header file in C++ mode. I've filled it with copies of existing test functions from other files in that directory, including a few moderately tricky cases of overloading (in particular one that relies on the strict-polymorphism attribute added in D72518). (I considered making //every// test in that directory compile in both C and C++ mode and check the code generation was identical. But I think that would increase testing time by more than the value it adds, and also update_cc_test_checks gets confused when the output function name varies between RUN lines.) Reviewers: LukeGeeson, MarkMurrayARM, miyuki, dmgreen Reviewed By: MarkMurrayARM Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73268
2020-01-23 22:10:24 +08:00
// CHECK-NEXT: [[DOTSPLAT:%.*]] = shufflevector <8 x half> [[DOTSPLATINSERT]], <8 x half> undef, <8 x i32> zeroinitializer
[CodeGen] fix test to be (mostly) independent of LLVM optimizer; NFC This test would break with the proposed change to IR canonicalization in D79171. The test tried to do the right thing by only using -mem2reg with opt, but it was using -O3 before that step, so the opt part was meaningless.
2020-05-10 23:25:37 +08:00
// CHECK-NEXT: [[TMP2:%.*]] = fcmp oeq <8 x half> [[A:%.*]], [[DOTSPLAT]]
// CHECK-NEXT: [[TMP3:%.*]] = call i32 @llvm.arm.mve.pred.v2i.v8i1(<8 x i1> [[TMP2]])
[ARM,MVE] Make the MVE intrinsics work in C++! Summary: Apparently nobody has tried this in months of development. It turns out that `FunctionDecl::getBuiltinID` will never consider a function to be a builtin if it is in C++ and not extern "C". So none of the function declarations in <arm_mve.h> are recognized as builtins when clang is compiling in C++ mode: it just emits calls to them as ordinary functions, which then turn out not to exist at link time. The trivial fix is to wrap most of arm_mve.h in an extern "C". Added a test in clang/test/CodeGen/arm-mve-intrinsics which checks basic functioning of the MVE header file in C++ mode. I've filled it with copies of existing test functions from other files in that directory, including a few moderately tricky cases of overloading (in particular one that relies on the strict-polymorphism attribute added in D72518). (I considered making //every// test in that directory compile in both C and C++ mode and check the code generation was identical. But I think that would increase testing time by more than the value it adds, and also update_cc_test_checks gets confused when the output function name varies between RUN lines.) Reviewers: LukeGeeson, MarkMurrayARM, miyuki, dmgreen Reviewed By: MarkMurrayARM Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73268
2020-01-23 22:10:24 +08:00
// CHECK-NEXT: [[TMP4:%.*]] = trunc i32 [[TMP3]] to i16
// CHECK-NEXT: ret i16 [[TMP4]]
//
mve_pred16_t test_vcmpeqq_n_f16(float16x8_t a, float16_t b)
{
#ifdef POLYMORPHIC
return vcmpeqq(a, b);
#else /* POLYMORPHIC */
return vcmpeqq_n_f16(a, b);
#endif /* POLYMORPHIC */
}
// CHECK-LABEL: @_Z14test_vld1q_u16PKt(
// CHECK-NEXT: entry:
// CHECK-NEXT: [[TMP0:%.*]] = bitcast i16* [[BASE:%.*]] to <8 x i16>*
// CHECK-NEXT: [[TMP1:%.*]] = load <8 x i16>, <8 x i16>* [[TMP0]], align 2
// CHECK-NEXT: ret <8 x i16> [[TMP1]]
//
uint16x8_t test_vld1q_u16(const uint16_t *base)
{
#ifdef POLYMORPHIC
return vld1q(base);
#else /* POLYMORPHIC */
return vld1q_u16(base);
#endif /* POLYMORPHIC */
}
// CHECK-LABEL: @_Z16test_vst1q_p_s32Pi17__simd128_int32_tt(
// CHECK-NEXT: entry:
// CHECK-NEXT: [[TMP0:%.*]] = bitcast i32* [[BASE:%.*]] to <4 x i32>*
// CHECK-NEXT: [[TMP1:%.*]] = zext i16 [[P:%.*]] to i32
[CodeGen] fix test to be (mostly) independent of LLVM optimizer; NFC This test would break with the proposed change to IR canonicalization in D79171. The test tried to do the right thing by only using -mem2reg with opt, but it was using -O3 before that step, so the opt part was meaningless.
2020-05-10 23:25:37 +08:00
// CHECK-NEXT: [[TMP2:%.*]] = call <4 x i1> @llvm.arm.mve.pred.i2v.v4i1(i32 [[TMP1]])
// CHECK-NEXT: call void @llvm.masked.store.v4i32.p0v4i32(<4 x i32> [[VALUE:%.*]], <4 x i32>* [[TMP0]], i32 4, <4 x i1> [[TMP2]])
[ARM,MVE] Make the MVE intrinsics work in C++! Summary: Apparently nobody has tried this in months of development. It turns out that `FunctionDecl::getBuiltinID` will never consider a function to be a builtin if it is in C++ and not extern "C". So none of the function declarations in <arm_mve.h> are recognized as builtins when clang is compiling in C++ mode: it just emits calls to them as ordinary functions, which then turn out not to exist at link time. The trivial fix is to wrap most of arm_mve.h in an extern "C". Added a test in clang/test/CodeGen/arm-mve-intrinsics which checks basic functioning of the MVE header file in C++ mode. I've filled it with copies of existing test functions from other files in that directory, including a few moderately tricky cases of overloading (in particular one that relies on the strict-polymorphism attribute added in D72518). (I considered making //every// test in that directory compile in both C and C++ mode and check the code generation was identical. But I think that would increase testing time by more than the value it adds, and also update_cc_test_checks gets confused when the output function name varies between RUN lines.) Reviewers: LukeGeeson, MarkMurrayARM, miyuki, dmgreen Reviewed By: MarkMurrayARM Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73268
2020-01-23 22:10:24 +08:00
// CHECK-NEXT: ret void
//
void test_vst1q_p_s32(int32_t *base, int32x4_t value, mve_pred16_t p)
{
#ifdef POLYMORPHIC
vst1q_p(base, value, p);
#else /* POLYMORPHIC */
vst1q_p_s32(base, value, p);
#endif /* POLYMORPHIC */
}
// CHECK-LABEL: @_Z30test_vldrdq_gather_base_wb_s64P18__simd128_uint64_t(
// CHECK-NEXT: entry:
// CHECK-NEXT: [[TMP0:%.*]] = load <2 x i64>, <2 x i64>* [[ADDR:%.*]], align 8
[CodeGen] fix test to be (mostly) independent of LLVM optimizer; NFC This test would break with the proposed change to IR canonicalization in D79171. The test tried to do the right thing by only using -mem2reg with opt, but it was using -O3 before that step, so the opt part was meaningless.
2020-05-10 23:25:37 +08:00
// CHECK-NEXT: [[TMP1:%.*]] = call { <2 x i64>, <2 x i64> } @llvm.arm.mve.vldr.gather.base.wb.v2i64.v2i64(<2 x i64> [[TMP0]], i32 576)
[ARM,MVE] Make the MVE intrinsics work in C++! Summary: Apparently nobody has tried this in months of development. It turns out that `FunctionDecl::getBuiltinID` will never consider a function to be a builtin if it is in C++ and not extern "C". So none of the function declarations in <arm_mve.h> are recognized as builtins when clang is compiling in C++ mode: it just emits calls to them as ordinary functions, which then turn out not to exist at link time. The trivial fix is to wrap most of arm_mve.h in an extern "C". Added a test in clang/test/CodeGen/arm-mve-intrinsics which checks basic functioning of the MVE header file in C++ mode. I've filled it with copies of existing test functions from other files in that directory, including a few moderately tricky cases of overloading (in particular one that relies on the strict-polymorphism attribute added in D72518). (I considered making //every// test in that directory compile in both C and C++ mode and check the code generation was identical. But I think that would increase testing time by more than the value it adds, and also update_cc_test_checks gets confused when the output function name varies between RUN lines.) Reviewers: LukeGeeson, MarkMurrayARM, miyuki, dmgreen Reviewed By: MarkMurrayARM Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73268
2020-01-23 22:10:24 +08:00
// CHECK-NEXT: [[TMP2:%.*]] = extractvalue { <2 x i64>, <2 x i64> } [[TMP1]], 1
// CHECK-NEXT: store <2 x i64> [[TMP2]], <2 x i64>* [[ADDR]], align 8
// CHECK-NEXT: [[TMP3:%.*]] = extractvalue { <2 x i64>, <2 x i64> } [[TMP1]], 0
// CHECK-NEXT: ret <2 x i64> [[TMP3]]
//
int64x2_t test_vldrdq_gather_base_wb_s64(uint64x2_t *addr)
{
return vldrdq_gather_base_wb_s64(addr, 0x240);
}
// CHECK-LABEL: @_Z31test_vstrwq_scatter_base_wb_u32P18__simd128_uint32_tS_(
// CHECK-NEXT: entry:
// CHECK-NEXT: [[TMP0:%.*]] = load <4 x i32>, <4 x i32>* [[ADDR:%.*]], align 8
[CodeGen] fix test to be (mostly) independent of LLVM optimizer; NFC This test would break with the proposed change to IR canonicalization in D79171. The test tried to do the right thing by only using -mem2reg with opt, but it was using -O3 before that step, so the opt part was meaningless.
2020-05-10 23:25:37 +08:00
// CHECK-NEXT: [[TMP1:%.*]] = call <4 x i32> @llvm.arm.mve.vstr.scatter.base.wb.v4i32.v4i32(<4 x i32> [[TMP0]], i32 64, <4 x i32> [[VALUE:%.*]])
[ARM,MVE] Make the MVE intrinsics work in C++! Summary: Apparently nobody has tried this in months of development. It turns out that `FunctionDecl::getBuiltinID` will never consider a function to be a builtin if it is in C++ and not extern "C". So none of the function declarations in <arm_mve.h> are recognized as builtins when clang is compiling in C++ mode: it just emits calls to them as ordinary functions, which then turn out not to exist at link time. The trivial fix is to wrap most of arm_mve.h in an extern "C". Added a test in clang/test/CodeGen/arm-mve-intrinsics which checks basic functioning of the MVE header file in C++ mode. I've filled it with copies of existing test functions from other files in that directory, including a few moderately tricky cases of overloading (in particular one that relies on the strict-polymorphism attribute added in D72518). (I considered making //every// test in that directory compile in both C and C++ mode and check the code generation was identical. But I think that would increase testing time by more than the value it adds, and also update_cc_test_checks gets confused when the output function name varies between RUN lines.) Reviewers: LukeGeeson, MarkMurrayARM, miyuki, dmgreen Reviewed By: MarkMurrayARM Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73268
2020-01-23 22:10:24 +08:00
// CHECK-NEXT: store <4 x i32> [[TMP1]], <4 x i32>* [[ADDR]], align 8
// CHECK-NEXT: ret void
//
void test_vstrwq_scatter_base_wb_u32(uint32x4_t *addr, uint32x4_t value)
{
#ifdef POLYMORPHIC
vstrwq_scatter_base_wb(addr, 0x40, value);
#else /* POLYMORPHIC */
vstrwq_scatter_base_wb_u32(addr, 0x40, value);
#endif /* POLYMORPHIC */
}