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/attr-target-x86.c

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

73 lines
4.1 KiB
C
Raw Normal View History

[X86] Add support 'tune' in target attribute This adds parsing and codegen support for tune in target attribute. I've implemented this so that arch in the target attribute implicitly disables tune from the command line. I'm not sure what gcc does here. But since -march implies -mtune. I assume 'arch' in the target attribute implies tune in the target attribute. Differential Revision: https://reviews.llvm.org/D86187
2020-08-20 06:58:16 +08:00
// RUN: %clang_cc1 -triple i686-linux-gnu -target-cpu i686 -tune-cpu i686 -emit-llvm %s -o - | FileCheck %s
Add support for the the target attribute. Modeled after the gcc attribute of the same name, this feature allows source level annotations to correspond to backend code generation. In llvm particular parlance, this allows the adding of subtarget features and changing the cpu for a particular function based on source level hints. This has been added into the existing support for function level attributes without particular verification for any target outside of whether or not the backend will support the features/cpu given (similar to section, etc). llvm-svn: 239579
2015-06-12 09:35:52 +08:00
int baz(int a) { return 4; }
int __attribute__((target("avx,sse4.2,arch=ivybridge"))) foo(int a) { return 4; }
Handle fpmath= in the target attribute. Right now we're ignoring the fpmath attribute since there's no backend support for a feature like this and to do so would require checking the validity of the strings and doing general subtarget feature parsing of valid and invalid features with the target attribute feature. llvm-svn: 239582
2015-06-12 09:36:00 +08:00
int __attribute__((target("fpmath=387"))) koala(int a) { return 4; }
Add support for tune= to the target attribute support by ignoring it. We don't currently support the -mtune option in any useful way so ignoring the annotation is fine. llvm-svn: 239580
2015-06-12 09:35:56 +08:00
Target attribute syntax compatibility fix - gcc uses no- rather than mno-. llvm-svn: 246197
2015-08-28 04:05:48 +08:00
int __attribute__((target("no-sse2"))) echidna(int a) { return 4; }
Handle -mno-<feature> in target attribute strings by replacing the -mno- with a -<feature> to match how we handle this in the rest of the frontend. llvm-svn: 239581
2015-06-12 09:35:58 +08:00
Fix sse4 for target attribute feature additions. This reinstates part of the hack removed in r233223, by special casing sse4 as part of the feature additions. The notable change here is that we consider it only as part of setting the SSE level and not as part of the actual target features set which handles setting the rest of the masks. llvm-svn: 241130
2015-07-01 08:08:32 +08:00
int __attribute__((target("sse4"))) panda(int a) { return 4; }
[X86] Add a target attribute test for no-sse4. llvm-svn: 316681
2017-10-27 01:54:22 +08:00
int __attribute__((target("no-sse4"))) narwhal(int a) { return 4; }
Fix sse4 for target attribute feature additions. This reinstates part of the hack removed in r233223, by special casing sse4 as part of the feature additions. The notable change here is that we consider it only as part of setting the SSE level and not as part of the actual target features set which handles setting the rest of the masks. llvm-svn: 241130
2015-07-01 08:08:32 +08:00
Add support for the the target attribute. Modeled after the gcc attribute of the same name, this feature allows source level annotations to correspond to backend code generation. In llvm particular parlance, this allows the adding of subtarget features and changing the cpu for a particular function based on source level hints. This has been added into the existing support for function level attributes without particular verification for any target outside of whether or not the backend will support the features/cpu given (similar to section, etc). llvm-svn: 239579
2015-06-12 09:35:52 +08:00
int bar(int a) { return baz(a) + foo(a); }
Handle arbitrary whitespace in the target attribute support. This allows us to deal a bit more gracefully with inclusions done by macros, token pasting, or just code layout/formatting. llvm-svn: 241525
2015-07-07 07:51:59 +08:00
int __attribute__((target("avx, sse4.2, arch= ivybridge"))) qux(int a) { return 4; }
Target attribute syntax compatibility fix - gcc uses no- rather than mno-. llvm-svn: 246197
2015-08-28 04:05:48 +08:00
int __attribute__((target("no-aes, arch=ivybridge"))) qax(int a) { return 4; }
Handle arbitrary whitespace in the target attribute support. This allows us to deal a bit more gracefully with inclusions done by macros, token pasting, or just code layout/formatting. llvm-svn: 241525
2015-07-07 07:51:59 +08:00
Handle sse turning on mmx, but no -mmx not turning off SSE. Rationale : // sse3 __m128d test_mm_addsub_pd(__m128d A, __m128d B) { return _mm_addsub_pd(A, B); } // mmx void shift(__m64 a, __m64 b, int c) { _mm_slli_pi16(a, c); _mm_slli_pi32(a, c); _mm_slli_si64(a, c); _mm_srli_pi16(a, c); _mm_srli_pi32(a, c); _mm_srli_si64(a, c); _mm_srai_pi16(a, c); _mm_srai_pi32(a, c); } clang -msse3 -mno-mmx file.c -c For this code we should be able to explicitly turn off MMX without affecting the compilation of the SSE3 function and then diagnose and error on compiling the MMX function. This is a preparatory patch to the actual diagnosis code which is coming in a future patch. This sets us up to have the correct information where we need it and verifies that it's being emitted for the backend to handle. llvm-svn: 249733
2015-10-09 04:10:18 +08:00
int __attribute__((target("no-mmx"))) qq(int a) { return 40; }
Filter out invalid 'target' items from being passed to LLVM Craig noticed that CodeGen wasn't properly ignoring the values sent to the target attribute. This patch ignores them. This patch also sets the 'default' for this checking to 'supported', since only X86 has implemented the support for checking valid CPU names and Feature Names. One test was changed to i686, since it uses a lakemont, which would otherwise be prohibited in x86_64. Differential Revision: https://reviews.llvm.org/D39357 llvm-svn: 316783
2017-10-28 02:32:23 +08:00
int __attribute__((target("arch=lakemont,mmx"))) lake(int a) { return 4; }
[X86] Introduction of -march=lakemont. Differential Revision: http://reviews.llvm.org/D18651 llvm-svn: 265405
2016-04-05 23:04:26 +08:00
Make attribute-target on a Definition-after-use update the LLVM attributes As reported here: https://bugs.llvm.org/show_bug.cgi?id=36301 The issue is that the 'use' causes the plain declaration to emit the attributes to LLVM-IR. However, if the definition added it later, these would silently disappear. This commit extracts that logic to its own function in CodeGenModule, and has the attribute-applications done during 'definition' update the attributes properly. Differential Revision: https://reviews.llvm.org/D43095 llvm-svn: 324907
2018-02-13 01:01:41 +08:00
int use_before_def(void);
int useage(void){
return use_before_def();
}
// Adding the attribute to a definition does update it in IR.
int __attribute__((target("arch=lakemont,mmx"))) use_before_def(void) {
return 5;
}
[X86] Add support 'tune' in target attribute This adds parsing and codegen support for tune in target attribute. I've implemented this so that arch in the target attribute implicitly disables tune from the command line. I'm not sure what gcc does here. But since -march implies -mtune. I assume 'arch' in the target attribute implies tune in the target attribute. Differential Revision: https://reviews.llvm.org/D86187
2020-08-20 06:58:16 +08:00
int __attribute__((target("tune=sandybridge"))) walrus(int a) { return 4; }
Make attribute-target on a Definition-after-use update the LLVM attributes As reported here: https://bugs.llvm.org/show_bug.cgi?id=36301 The issue is that the 'use' causes the plain declaration to emit the attributes to LLVM-IR. However, if the definition added it later, these would silently disappear. This commit extracts that logic to its own function in CodeGenModule, and has the attribute-applications done during 'definition' update the attributes properly. Differential Revision: https://reviews.llvm.org/D43095 llvm-svn: 324907
2018-02-13 01:01:41 +08:00
[X86] Support -march=x86-64-v[234] PR47686. These micro-architecture levels are defined in the x86-64 psABI: https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9 GCC 11 will support these levels. Note, -mtune=x86-64-v[234] are invalid and __builtin_cpu_is cannot be used on them. Reviewed By: craig.topper, RKSimon Differential Revision: https://reviews.llvm.org/D89197
2020-10-13 00:35:22 +08:00
void __attribute__((target("arch=x86-64-v2"))) x86_64_v2() {}
void __attribute__((target("arch=x86-64-v3"))) x86_64_v3() {}
void __attribute__((target("arch=x86-64-v4"))) x86_64_v4() {}
Add support for the the target attribute. Modeled after the gcc attribute of the same name, this feature allows source level annotations to correspond to backend code generation. In llvm particular parlance, this allows the adding of subtarget features and changing the cpu for a particular function based on source level hints. This has been added into the existing support for function level attributes without particular verification for any target outside of whether or not the backend will support the features/cpu given (similar to section, etc). llvm-svn: 239579
2015-06-12 09:35:52 +08:00
// Check that we emit the additional subtarget and cpu features for foo and not for baz or bar.
// CHECK: baz{{.*}} #0
// CHECK: foo{{.*}} #1
Handle fpmath= in the target attribute. Right now we're ignoring the fpmath attribute since there's no backend support for a feature like this and to do so would require checking the validity of the strings and doing general subtarget feature parsing of valid and invalid features with the target attribute feature. llvm-svn: 239582
2015-06-12 09:36:00 +08:00
// We're currently ignoring the fpmath attribute so koala should be identical to baz and bar.
// CHECK: koala{{.*}} #0
Handle -mno-<feature> in target attribute strings by replacing the -mno- with a -<feature> to match how we handle this in the rest of the frontend. llvm-svn: 239581
2015-06-12 09:35:58 +08:00
// CHECK: echidna{{.*}} #2
Add a check for a function we're not testing. llvm-svn: 246355
2015-08-29 10:59:37 +08:00
// CHECK: panda{{.*}} #3
[X86] Add a target attribute test for no-sse4. llvm-svn: 316681
2017-10-27 01:54:22 +08:00
// CHECK: narwhal{{.*}} #4
Add support for the the target attribute. Modeled after the gcc attribute of the same name, this feature allows source level annotations to correspond to backend code generation. In llvm particular parlance, this allows the adding of subtarget features and changing the cpu for a particular function based on source level hints. This has been added into the existing support for function level attributes without particular verification for any target outside of whether or not the backend will support the features/cpu given (similar to section, etc). llvm-svn: 239579
2015-06-12 09:35:52 +08:00
// CHECK: bar{{.*}} #0
Handle arbitrary whitespace in the target attribute support. This allows us to deal a bit more gracefully with inclusions done by macros, token pasting, or just code layout/formatting. llvm-svn: 241525
2015-07-07 07:51:59 +08:00
// CHECK: qux{{.*}} #1
[X86] Add a target attribute test for no-sse4. llvm-svn: 316681
2017-10-27 01:54:22 +08:00
// CHECK: qax{{.*}} #5
// CHECK: qq{{.*}} #6
// CHECK: lake{{.*}} #7
Make attribute-target on a Definition-after-use update the LLVM attributes As reported here: https://bugs.llvm.org/show_bug.cgi?id=36301 The issue is that the 'use' causes the plain declaration to emit the attributes to LLVM-IR. However, if the definition added it later, these would silently disappear. This commit extracts that logic to its own function in CodeGenModule, and has the attribute-applications done during 'definition' update the attributes properly. Differential Revision: https://reviews.llvm.org/D43095 llvm-svn: 324907
2018-02-13 01:01:41 +08:00
// CHECK: use_before_def{{.*}} #7
[X86] Add support 'tune' in target attribute This adds parsing and codegen support for tune in target attribute. I've implemented this so that arch in the target attribute implicitly disables tune from the command line. I'm not sure what gcc does here. But since -march implies -mtune. I assume 'arch' in the target attribute implies tune in the target attribute. Differential Revision: https://reviews.llvm.org/D86187
2020-08-20 06:58:16 +08:00
// CHECK: walrus{{.*}} #8
// CHECK: #0 = {{.*}}"target-cpu"="i686" "target-features"="+cx8,+x87" "tune-cpu"="i686"
[X86] Correct the value of MaxAtomicInlineWidth for pre-586 cpus Use the new cx8 feature flag that was added to the backend to represent support for cmpxchg8b. Use this flag to set the MaxAtomicInlineWidth. This also assumes all the cmpxchg instructions are enabled for CK_Generic which is what cc1 defaults to when nothing is specified. Differential Revision: https://reviews.llvm.org/D59566 llvm-svn: 356709
2019-03-22 04:36:08 +08:00
// CHECK: #1 = {{.*}}"target-cpu"="ivybridge" "target-features"="+avx,+cx16,+cx8,+f16c,+fsgsbase,+fxsr,+mmx,+pclmul,+popcnt,+rdrnd,+sahf,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87,+xsave,+xsaveopt"
[X86] Add support 'tune' in target attribute This adds parsing and codegen support for tune in target attribute. I've implemented this so that arch in the target attribute implicitly disables tune from the command line. I'm not sure what gcc does here. But since -march implies -mtune. I assume 'arch' in the target attribute implies tune in the target attribute. Differential Revision: https://reviews.llvm.org/D86187
2020-08-20 06:58:16 +08:00
// CHECK-NOT: tune-cpu
[X86] Support Intel avxvnni This patch mainly made the following changes: 1. Support AVX-VNNI instructions; 2. Introduce ExplicitVEXPrefix flag so that vpdpbusd/vpdpbusds/vpdpbusds/vpdpbusds instructions only use vex-encoding when user explicity add {vex} prefix. Differential Revision: https://reviews.llvm.org/D89105
2020-10-30 12:58:05 +08:00
// CHECK: #2 = {{.*}}"target-cpu"="i686" "target-features"="+cx8,+x87,-aes,-avx,-avx2,-avx512bf16,-avx512bitalg,-avx512bw,-avx512cd,-avx512dq,-avx512er,-avx512f,-avx512ifma,-avx512pf,-avx512vbmi,-avx512vbmi2,-avx512vl,-avx512vnni,-avx512vp2intersect,-avx512vpopcntdq,-avxvnni,-f16c,-fma,-fma4,-gfni,-kl,-pclmul,-sha,-sse2,-sse3,-sse4.1,-sse4.2,-sse4a,-ssse3,-vaes,-vpclmulqdq,-widekl,-xop" "tune-cpu"="i686"
[X86] Add support 'tune' in target attribute This adds parsing and codegen support for tune in target attribute. I've implemented this so that arch in the target attribute implicitly disables tune from the command line. I'm not sure what gcc does here. But since -march implies -mtune. I assume 'arch' in the target attribute implies tune in the target attribute. Differential Revision: https://reviews.llvm.org/D86187
2020-08-20 06:58:16 +08:00
// CHECK: #3 = {{.*}}"target-cpu"="i686" "target-features"="+cx8,+mmx,+popcnt,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87" "tune-cpu"="i686"
[X86] Support Intel avxvnni This patch mainly made the following changes: 1. Support AVX-VNNI instructions; 2. Introduce ExplicitVEXPrefix flag so that vpdpbusd/vpdpbusds/vpdpbusds/vpdpbusds instructions only use vex-encoding when user explicity add {vex} prefix. Differential Revision: https://reviews.llvm.org/D89105
2020-10-30 12:58:05 +08:00
// CHECK: #4 = {{.*}}"target-cpu"="i686" "target-features"="+cx8,+x87,-avx,-avx2,-avx512bf16,-avx512bitalg,-avx512bw,-avx512cd,-avx512dq,-avx512er,-avx512f,-avx512ifma,-avx512pf,-avx512vbmi,-avx512vbmi2,-avx512vl,-avx512vnni,-avx512vp2intersect,-avx512vpopcntdq,-avxvnni,-f16c,-fma,-fma4,-sse4.1,-sse4.2,-vaes,-vpclmulqdq,-xop" "tune-cpu"="i686"
[X86] Correct the value of MaxAtomicInlineWidth for pre-586 cpus Use the new cx8 feature flag that was added to the backend to represent support for cmpxchg8b. Use this flag to set the MaxAtomicInlineWidth. This also assumes all the cmpxchg instructions are enabled for CK_Generic which is what cc1 defaults to when nothing is specified. Differential Revision: https://reviews.llvm.org/D59566 llvm-svn: 356709
2019-03-22 04:36:08 +08:00
// CHECK: #5 = {{.*}}"target-cpu"="ivybridge" "target-features"="+avx,+cx16,+cx8,+f16c,+fsgsbase,+fxsr,+mmx,+pclmul,+popcnt,+rdrnd,+sahf,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87,+xsave,+xsaveopt,-aes,-vaes"
[X86] Add support 'tune' in target attribute This adds parsing and codegen support for tune in target attribute. I've implemented this so that arch in the target attribute implicitly disables tune from the command line. I'm not sure what gcc does here. But since -march implies -mtune. I assume 'arch' in the target attribute implies tune in the target attribute. Differential Revision: https://reviews.llvm.org/D86187
2020-08-20 06:58:16 +08:00
// CHECK-NOT: tune-cpu
[X86] Correct the value of MaxAtomicInlineWidth for pre-586 cpus Use the new cx8 feature flag that was added to the backend to represent support for cmpxchg8b. Use this flag to set the MaxAtomicInlineWidth. This also assumes all the cmpxchg instructions are enabled for CK_Generic which is what cc1 defaults to when nothing is specified. Differential Revision: https://reviews.llvm.org/D59566 llvm-svn: 356709
2019-03-22 04:36:08 +08:00
// CHECK: #6 = {{.*}}"target-cpu"="i686" "target-features"="+cx8,+x87,-3dnow,-3dnowa,-mmx"
// CHECK: #7 = {{.*}}"target-cpu"="lakemont" "target-features"="+cx8,+mmx"
[X86] Add support 'tune' in target attribute This adds parsing and codegen support for tune in target attribute. I've implemented this so that arch in the target attribute implicitly disables tune from the command line. I'm not sure what gcc does here. But since -march implies -mtune. I assume 'arch' in the target attribute implies tune in the target attribute. Differential Revision: https://reviews.llvm.org/D86187
2020-08-20 06:58:16 +08:00
// CHECK-NOT: tune-cpu
// CHECK: #8 = {{.*}}"target-cpu"="i686" "target-features"="+cx8,+x87" "tune-cpu"="sandybridge"
[X86] Support -march=x86-64-v[234] PR47686. These micro-architecture levels are defined in the x86-64 psABI: https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9 GCC 11 will support these levels. Note, -mtune=x86-64-v[234] are invalid and __builtin_cpu_is cannot be used on them. Reviewed By: craig.topper, RKSimon Differential Revision: https://reviews.llvm.org/D89197
2020-10-13 00:35:22 +08:00
// CHECK: "target-cpu"="x86-64-v2"
// CHECK-SAME: "target-features"="+cx16,+cx8,+fxsr,+mmx,+popcnt,+sahf,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87"
// CHECK: "target-cpu"="x86-64-v3"
// CHECK-SAME: "target-features"="+avx,+avx2,+bmi,+bmi2,+cx16,+cx8,+f16c,+fma,+fxsr,+lzcnt,+mmx,+movbe,+popcnt,+sahf,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87,+xsave"
// CHECK: "target-cpu"="x86-64-v4"
// CHECK-SAME: "target-features"="+avx,+avx2,+avx512bw,+avx512cd,+avx512dq,+avx512f,+avx512vl,+bmi,+bmi2,+cx16,+cx8,+f16c,+fma,+fxsr,+lzcnt,+mmx,+movbe,+popcnt,+sahf,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87,+xsave"