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/target-builtin-noerror.c

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

134 lines
4.3 KiB
C
Raw Normal View History

Mark this test as requiring and x86 registered target. llvm-svn: 250475
2015-10-16 08:14:36 +08:00
// REQUIRES: x86-registered-target
Add an error when calling a builtin that requires features that don't match the feature set of the function that they're being called from. This ensures that we can effectively diagnose some[1] code that would instead ICE in the backend with a failure to select message. Example: __m128d foo(__m128d a, __m128d b) { return __builtin_ia32_addsubps(b, a); } compiled for normal x86_64 via: clang -target x86_64-linux-gnu -c would fail to compile in the back end because the normal subtarget features for x86_64 only include sse2 and the builtin requires sse3. [1] We're still not erroring on: __m128i bar(__m128i const *p) { return _mm_lddqu_si128(p); } where we should fail and error on an always_inline function being inlined into a function that doesn't support the subtarget features required. llvm-svn: 250473
2015-10-16 07:47:11 +08:00
// RUN: %clang_cc1 %s -triple=x86_64-linux-gnu -S -o -
#define __MM_MALLOC_H
#include <x86intrin.h>
// No warnings.
extern __m256i a;
Implement AVX ABI Warning/error The x86-64 "avx" feature changes how >128 bit vector types are passed, instead of being passed in separate 128 bit registers, they can be passed in 256 bit registers. "avx512f" does the same thing, except it switches from 256 bit registers to 512 bit registers. The result of both of these is an ABI incompatibility between functions compiled with and without these features. This patch implements a warning/error pair upon an attempt to call a function that would run afoul of this. First, if a function is called that would have its ABI changed, we issue a warning. Second, if said call is made in a situation where the caller and callee are known to have different calling conventions (such as the case of 'target'), we instead issue an error. Differential Revision: https://reviews.llvm.org/D82562
2020-06-24 03:14:09 +08:00
int __attribute__((target("avx"))) bar() {
Add an error when calling a builtin that requires features that don't match the feature set of the function that they're being called from. This ensures that we can effectively diagnose some[1] code that would instead ICE in the backend with a failure to select message. Example: __m128d foo(__m128d a, __m128d b) { return __builtin_ia32_addsubps(b, a); } compiled for normal x86_64 via: clang -target x86_64-linux-gnu -c would fail to compile in the back end because the normal subtarget features for x86_64 only include sse2 and the builtin requires sse3. [1] We're still not erroring on: __m128i bar(__m128i const *p) { return _mm_lddqu_si128(p); } where we should fail and error on an always_inline function being inlined into a function that doesn't support the subtarget features required. llvm-svn: 250473
2015-10-16 07:47:11 +08:00
return _mm256_extract_epi32(a, 3);
}
int baz() {
Implement AVX ABI Warning/error The x86-64 "avx" feature changes how >128 bit vector types are passed, instead of being passed in separate 128 bit registers, they can be passed in 256 bit registers. "avx512f" does the same thing, except it switches from 256 bit registers to 512 bit registers. The result of both of these is an ABI incompatibility between functions compiled with and without these features. This patch implements a warning/error pair upon an attempt to call a function that would run afoul of this. First, if a function is called that would have its ABI changed, we issue a warning. Second, if said call is made in a situation where the caller and callee are known to have different calling conventions (such as the case of 'target'), we instead issue an error. Differential Revision: https://reviews.llvm.org/D82562
2020-06-24 03:14:09 +08:00
return bar();
Add an error when calling a builtin that requires features that don't match the feature set of the function that they're being called from. This ensures that we can effectively diagnose some[1] code that would instead ICE in the backend with a failure to select message. Example: __m128d foo(__m128d a, __m128d b) { return __builtin_ia32_addsubps(b, a); } compiled for normal x86_64 via: clang -target x86_64-linux-gnu -c would fail to compile in the back end because the normal subtarget features for x86_64 only include sse2 and the builtin requires sse3. [1] We're still not erroring on: __m128i bar(__m128i const *p) { return _mm_lddqu_si128(p); } where we should fail and error on an always_inline function being inlined into a function that doesn't support the subtarget features required. llvm-svn: 250473
2015-10-16 07:47:11 +08:00
}
Implement AVX ABI Warning/error The x86-64 "avx" feature changes how >128 bit vector types are passed, instead of being passed in separate 128 bit registers, they can be passed in 256 bit registers. "avx512f" does the same thing, except it switches from 256 bit registers to 512 bit registers. The result of both of these is an ABI incompatibility between functions compiled with and without these features. This patch implements a warning/error pair upon an attempt to call a function that would run afoul of this. First, if a function is called that would have its ABI changed, we issue a warning. Second, if said call is made in a situation where the caller and callee are known to have different calling conventions (such as the case of 'target'), we instead issue an error. Differential Revision: https://reviews.llvm.org/D82562
2020-06-24 03:14:09 +08:00
int __attribute__((target("avx"))) qq_avx() {
Add an error when calling a builtin that requires features that don't match the feature set of the function that they're being called from. This ensures that we can effectively diagnose some[1] code that would instead ICE in the backend with a failure to select message. Example: __m128d foo(__m128d a, __m128d b) { return __builtin_ia32_addsubps(b, a); } compiled for normal x86_64 via: clang -target x86_64-linux-gnu -c would fail to compile in the back end because the normal subtarget features for x86_64 only include sse2 and the builtin requires sse3. [1] We're still not erroring on: __m128i bar(__m128i const *p) { return _mm_lddqu_si128(p); } where we should fail and error on an always_inline function being inlined into a function that doesn't support the subtarget features required. llvm-svn: 250473
2015-10-16 07:47:11 +08:00
return _mm256_extract_epi32(a, 3);
}
int qq_noavx() {
return 0;
}
extern __m256i a;
int qq() {
if (__builtin_cpu_supports("avx"))
Implement AVX ABI Warning/error The x86-64 "avx" feature changes how >128 bit vector types are passed, instead of being passed in separate 128 bit registers, they can be passed in 256 bit registers. "avx512f" does the same thing, except it switches from 256 bit registers to 512 bit registers. The result of both of these is an ABI incompatibility between functions compiled with and without these features. This patch implements a warning/error pair upon an attempt to call a function that would run afoul of this. First, if a function is called that would have its ABI changed, we issue a warning. Second, if said call is made in a situation where the caller and callee are known to have different calling conventions (such as the case of 'target'), we instead issue an error. Differential Revision: https://reviews.llvm.org/D82562
2020-06-24 03:14:09 +08:00
return qq_avx();
Add an error when calling a builtin that requires features that don't match the feature set of the function that they're being called from. This ensures that we can effectively diagnose some[1] code that would instead ICE in the backend with a failure to select message. Example: __m128d foo(__m128d a, __m128d b) { return __builtin_ia32_addsubps(b, a); } compiled for normal x86_64 via: clang -target x86_64-linux-gnu -c would fail to compile in the back end because the normal subtarget features for x86_64 only include sse2 and the builtin requires sse3. [1] We're still not erroring on: __m128i bar(__m128i const *p) { return _mm_lddqu_si128(p); } where we should fail and error on an always_inline function being inlined into a function that doesn't support the subtarget features required. llvm-svn: 250473
2015-10-16 07:47:11 +08:00
else
return qq_noavx();
}
Handle target builtin options that are all required rather than only one of a group of possibilities. This changes the syntax in the builtin files to represent: , as the and operator | as the or operator The former syntax matches how the backend tablegen files represent multiple subtarget features being required. Updated the builtin and intrinsic headers accordingly for the new syntax. llvm-svn: 251388
2015-10-27 14:11:03 +08:00
// Test that fma and fma4 are both separately and combined valid for an fma intrinsic.
__m128 __attribute__((target("fma"))) fma_1(__m128 a, __m128 b, __m128 c) {
return __builtin_ia32_vfmaddps(a, b, c);
}
__m128 __attribute__((target("fma4"))) fma_2(__m128 a, __m128 b, __m128 c) {
return __builtin_ia32_vfmaddps(a, b, c);
}
__m128 __attribute__((target("fma,fma4"))) fma_3(__m128 a, __m128 b, __m128 c) {
return __builtin_ia32_vfmaddps(a, b, c);
}
Add all the avx512 flavors to __builtin_cpu_supports's list. This is matching what trunk gcc is accepting. Also adds a missing ssse3 case. PR27779. The amount of duplication here is annoying, maybe it should be factored into a separate .def file? llvm-svn: 270224
2016-05-20 23:21:08 +08:00
void verifyfeaturestrings() {
(void)__builtin_cpu_supports("cmov");
(void)__builtin_cpu_supports("mmx");
(void)__builtin_cpu_supports("popcnt");
(void)__builtin_cpu_supports("sse");
(void)__builtin_cpu_supports("sse2");
(void)__builtin_cpu_supports("sse3");
(void)__builtin_cpu_supports("ssse3");
(void)__builtin_cpu_supports("sse4.1");
(void)__builtin_cpu_supports("sse4.2");
(void)__builtin_cpu_supports("avx");
(void)__builtin_cpu_supports("avx2");
(void)__builtin_cpu_supports("sse4a");
(void)__builtin_cpu_supports("fma4");
(void)__builtin_cpu_supports("xop");
(void)__builtin_cpu_supports("fma");
(void)__builtin_cpu_supports("avx512f");
(void)__builtin_cpu_supports("bmi");
(void)__builtin_cpu_supports("bmi2");
(void)__builtin_cpu_supports("aes");
(void)__builtin_cpu_supports("pclmul");
(void)__builtin_cpu_supports("avx512vl");
(void)__builtin_cpu_supports("avx512bw");
(void)__builtin_cpu_supports("avx512dq");
(void)__builtin_cpu_supports("avx512cd");
(void)__builtin_cpu_supports("avx512er");
(void)__builtin_cpu_supports("avx512pf");
(void)__builtin_cpu_supports("avx512vbmi");
(void)__builtin_cpu_supports("avx512ifma");
[X86] Support 'avx5124vnniw' and 'avx5124fmaps' for __builtin_cpu_supports. They still need to be implemented in the intrinsics, the command line, and the backend. But this change isn't dependent on any of that and resolves a TODO. llvm-svn: 310386
2017-08-09 01:43:44 +08:00
(void)__builtin_cpu_supports("avx5124vnniw");
(void)__builtin_cpu_supports("avx5124fmaps");
(void)__builtin_cpu_supports("avx512vpopcntdq");
[X86] Add support for more than 32 features for __builtin_cpu_is libgcc supports more than 32 features by adding a new 32-bit variable __cpu_features2. This adds the clang support for checking these feature bits. Patches for compiler-rt and llvm to support this are coming as well. Probably still need an additional patch for target multiversioning in clang. Differential Revision: https://reviews.llvm.org/D53458 llvm-svn: 344832
2018-10-20 11:51:52 +08:00
(void)__builtin_cpu_supports("avx512vbmi2");
(void)__builtin_cpu_supports("gfni");
(void)__builtin_cpu_supports("vpclmulqdq");
(void)__builtin_cpu_supports("avx512vnni");
(void)__builtin_cpu_supports("avx512bitalg");
[X86] Add support for avx512bf16 for __builtin_cpu_supports and compiler-rt's cpu indicator. llvm-svn: 370915
2019-09-05 00:01:43 +08:00
(void)__builtin_cpu_supports("avx512bf16");
[X86] Allow avx512vp2intersect to be used with __builtin_cpu_supports. compiler-rt and trunk libgcc support this now.
2020-05-22 09:16:02 +08:00
(void)__builtin_cpu_supports("avx512vp2intersect");
Add all the avx512 flavors to __builtin_cpu_supports's list. This is matching what trunk gcc is accepting. Also adds a missing ssse3 case. PR27779. The amount of duplication here is annoying, maybe it should be factored into a separate .def file? llvm-svn: 270224
2016-05-20 23:21:08 +08:00
}
[X86] Implement __builtin_cpu_is This patch adds support for __builtin_cpu_is. I've tried to match the strings supported to the latest version of gcc. Differential Revision: https://reviews.llvm.org/D35449 llvm-svn: 310657
2017-08-11 04:28:30 +08:00
void verifycpustrings() {
[X86] Add a stub for Intel's alderlake. No scheduling, no autodetection.
2020-10-25 00:00:33 +08:00
(void)__builtin_cpu_is("alderlake");
[X86] Implement __builtin_cpu_is This patch adds support for __builtin_cpu_is. I've tried to match the strings supported to the latest version of gcc. Differential Revision: https://reviews.llvm.org/D35449 llvm-svn: 310657
2017-08-11 04:28:30 +08:00
(void)__builtin_cpu_is("amd");
(void)__builtin_cpu_is("amdfam10h");
(void)__builtin_cpu_is("amdfam15h");
[X86] Add support for 'amdfam17h' to __builtin_cpu_is to match gcc. The compiler-rt implementation already supported it, it just wasn't exposed. llvm-svn: 315517
2017-10-12 05:42:02 +08:00
(void)__builtin_cpu_is("amdfam17h");
[X86] Implement __builtin_cpu_is This patch adds support for __builtin_cpu_is. I've tried to match the strings supported to the latest version of gcc. Differential Revision: https://reviews.llvm.org/D35449 llvm-svn: 310657
2017-08-11 04:28:30 +08:00
(void)__builtin_cpu_is("atom");
(void)__builtin_cpu_is("barcelona");
(void)__builtin_cpu_is("bdver1");
(void)__builtin_cpu_is("bdver2");
(void)__builtin_cpu_is("bdver3");
(void)__builtin_cpu_is("bdver4");
(void)__builtin_cpu_is("bonnell");
(void)__builtin_cpu_is("broadwell");
(void)__builtin_cpu_is("btver1");
(void)__builtin_cpu_is("btver2");
[X86] Make sure 'knm' and 'cannonlake' are accepted by builtin_cpu_is llvm-svn: 318619
2017-11-19 12:12:33 +08:00
(void)__builtin_cpu_is("cannonlake");
[X86] Add 'znver2' and 'cascadelake' to the __builtin_cpu_is test. These are supported by at least libgcc trunk so we can include them now. llvm-svn: 354915
2019-02-27 03:20:04 +08:00
(void)__builtin_cpu_is("cascadelake");
[X86] Add 'cooperlake' and 'tigerlake' to __builtin_cpu_is. Cooperlake can be detect by compiler-rt now, but not libgcc yet. Tigerlake can't be detected by either. Both names are accepted by gcc. Hopefully the detection code will be in place soon.
2020-06-22 02:30:00 +08:00
(void)__builtin_cpu_is("cooperlake");
[X86] Implement __builtin_cpu_is This patch adds support for __builtin_cpu_is. I've tried to match the strings supported to the latest version of gcc. Differential Revision: https://reviews.llvm.org/D35449 llvm-svn: 310657
2017-08-11 04:28:30 +08:00
(void)__builtin_cpu_is("core2");
(void)__builtin_cpu_is("corei7");
[X86] Add support for more than 32 features for __builtin_cpu_is libgcc supports more than 32 features by adding a new 32-bit variable __cpu_features2. This adds the clang support for checking these feature bits. Patches for compiler-rt and llvm to support this are coming as well. Probably still need an additional patch for target multiversioning in clang. Differential Revision: https://reviews.llvm.org/D53458 llvm-svn: 344832
2018-10-20 11:51:52 +08:00
(void)__builtin_cpu_is("goldmont");
(void)__builtin_cpu_is("goldmont-plus");
[X86] Implement __builtin_cpu_is This patch adds support for __builtin_cpu_is. I've tried to match the strings supported to the latest version of gcc. Differential Revision: https://reviews.llvm.org/D35449 llvm-svn: 310657
2017-08-11 04:28:30 +08:00
(void)__builtin_cpu_is("haswell");
[X86] Add support for more than 32 features for __builtin_cpu_is libgcc supports more than 32 features by adding a new 32-bit variable __cpu_features2. This adds the clang support for checking these feature bits. Patches for compiler-rt and llvm to support this are coming as well. Probably still need an additional patch for target multiversioning in clang. Differential Revision: https://reviews.llvm.org/D53458 llvm-svn: 344832
2018-10-20 11:51:52 +08:00
(void)__builtin_cpu_is("icelake-client");
(void)__builtin_cpu_is("icelake-server");
[X86] Implement __builtin_cpu_is This patch adds support for __builtin_cpu_is. I've tried to match the strings supported to the latest version of gcc. Differential Revision: https://reviews.llvm.org/D35449 llvm-svn: 310657
2017-08-11 04:28:30 +08:00
(void)__builtin_cpu_is("intel");
(void)__builtin_cpu_is("istanbul");
(void)__builtin_cpu_is("ivybridge");
(void)__builtin_cpu_is("knl");
[X86] Make sure 'knm' and 'cannonlake' are accepted by builtin_cpu_is llvm-svn: 318619
2017-11-19 12:12:33 +08:00
(void)__builtin_cpu_is("knm");
[X86] Implement __builtin_cpu_is This patch adds support for __builtin_cpu_is. I've tried to match the strings supported to the latest version of gcc. Differential Revision: https://reviews.llvm.org/D35449 llvm-svn: 310657
2017-08-11 04:28:30 +08:00
(void)__builtin_cpu_is("nehalem");
[X86] Support -march=rocketlake Reviewed By: skan, craig.topper, MaskRay Differential Revision: https://reviews.llvm.org/D100085
2021-04-13 09:24:34 +08:00
(void)__builtin_cpu_is("rocketlake");
[X86] Implement __builtin_cpu_is This patch adds support for __builtin_cpu_is. I've tried to match the strings supported to the latest version of gcc. Differential Revision: https://reviews.llvm.org/D35449 llvm-svn: 310657
2017-08-11 04:28:30 +08:00
(void)__builtin_cpu_is("sandybridge");
(void)__builtin_cpu_is("shanghai");
(void)__builtin_cpu_is("silvermont");
(void)__builtin_cpu_is("skylake");
(void)__builtin_cpu_is("skylake-avx512");
(void)__builtin_cpu_is("slm");
[X86] Add 'cooperlake' and 'tigerlake' to __builtin_cpu_is. Cooperlake can be detect by compiler-rt now, but not libgcc yet. Tigerlake can't be detected by either. Both names are accepted by gcc. Hopefully the detection code will be in place soon.
2020-06-22 02:30:00 +08:00
(void)__builtin_cpu_is("tigerlake");
[X86] Support -march=sapphirerapids Support -march=sapphirerapids for x86. Compare with Icelake Server, it includes 14 more new features. They are amxtile, amxint8, amxbf16, avx512bf16, avx512vp2intersect, cldemote, enqcmd, movdir64b, movdiri, ptwrite, serialize, shstk, tsxldtrk, waitpkg. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D86503
2020-08-25 12:27:02 +08:00
(void)__builtin_cpu_is("sapphirerapids");
[X86] Add support for more than 32 features for __builtin_cpu_is libgcc supports more than 32 features by adding a new 32-bit variable __cpu_features2. This adds the clang support for checking these feature bits. Patches for compiler-rt and llvm to support this are coming as well. Probably still need an additional patch for target multiversioning in clang. Differential Revision: https://reviews.llvm.org/D53458 llvm-svn: 344832
2018-10-20 11:51:52 +08:00
(void)__builtin_cpu_is("tremont");
[X86] Implement __builtin_cpu_is This patch adds support for __builtin_cpu_is. I've tried to match the strings supported to the latest version of gcc. Differential Revision: https://reviews.llvm.org/D35449 llvm-svn: 310657
2017-08-11 04:28:30 +08:00
(void)__builtin_cpu_is("westmere");
(void)__builtin_cpu_is("znver1");
[X86] AMD znver2 enablement This patch enables the following 1) AMD family 17h "znver2" tune flag (-march, -mcpu). 2) ISAs that are enabled for "znver2" architecture. 3) For the time being, it uses the znver1 scheduler model. 4) Tests are updated. 5) This patch is the clang counterpart to D58343 Reviewers: craig.topper Tags: #clang Differential Revision: https://reviews.llvm.org/D58344 llvm-svn: 354899
2019-02-27 01:15:36 +08:00
(void)__builtin_cpu_is("znver2");
[X86] Autodetect znver3
2020-12-06 02:07:09 +08:00
(void)__builtin_cpu_is("znver3");
[X86] Implement __builtin_cpu_is This patch adds support for __builtin_cpu_is. I've tried to match the strings supported to the latest version of gcc. Differential Revision: https://reviews.llvm.org/D35449 llvm-svn: 310657
2017-08-11 04:28:30 +08:00
}