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
master
llvm-mirror/include/llvm/Support/X86TargetParser.def

205 lines
8.7 KiB
Modula-2
Raw Permalink Normal View History

[X86] Add a def file to CPU vendor, type, and subtype encodings used by Host.cpp Summary: I want to leverage this to clean up some of the code in clang. This will allow us to simplify D39521 which was trying to do some of the same. If we accurately keep the code in Host.cpp synced with new CPUs added to compile-rt/libgcc we should be able to use this file as a proxy for what's implemented in the libraries. The entries for the CPUs recognized by the libraries use separate macros that define additional parameters like the name for __builtin_cpu_is and an alias string for the couple cases where __builtin_cpu_is accepts two different names. All of the macros contain an ARCHNAME that is usually the same as the __builtin_cpu_is string, but sometimes isn't. This represents the name recognized by X86.td and -march. I'm following the precedent set by ARM and AArch64 and adding this information to lib/Support/TargetParser.cpp Reviewers: erichkeane, echristo, asbirlea Reviewed By: echristo Subscribers: llvm-commits, aemerson, kristof.beyls Differential Revision: https://reviews.llvm.org/D39782 llvm-svn: 317900
2017-11-10 18:10:57 +01:00
//===- X86TargetParser.def - X86 target parsing defines ---------*- C++ -*-===//
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 09:50:56 +01:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
[X86] Add a def file to CPU vendor, type, and subtype encodings used by Host.cpp Summary: I want to leverage this to clean up some of the code in clang. This will allow us to simplify D39521 which was trying to do some of the same. If we accurately keep the code in Host.cpp synced with new CPUs added to compile-rt/libgcc we should be able to use this file as a proxy for what's implemented in the libraries. The entries for the CPUs recognized by the libraries use separate macros that define additional parameters like the name for __builtin_cpu_is and an alias string for the couple cases where __builtin_cpu_is accepts two different names. All of the macros contain an ARCHNAME that is usually the same as the __builtin_cpu_is string, but sometimes isn't. This represents the name recognized by X86.td and -march. I'm following the precedent set by ARM and AArch64 and adding this information to lib/Support/TargetParser.cpp Reviewers: erichkeane, echristo, asbirlea Reviewed By: echristo Subscribers: llvm-commits, aemerson, kristof.beyls Differential Revision: https://reviews.llvm.org/D39782 llvm-svn: 317900
2017-11-10 18:10:57 +01:00
//
//===----------------------------------------------------------------------===//
//
// This file provides defines to build up the X86 target parser's logic.
//
//===----------------------------------------------------------------------===//
// NOTE: NO INCLUDE GUARD DESIRED!
#ifndef X86_VENDOR
[X86] Fix the parameter order in the default implementation of X86_VENDOR macro in X86TargetParser.def The default implementation doesn't do anything so the order doesn't matter, but good for cleanliness. llvm-svn: 318226
2017-11-15 00:54:28 +01:00
#define X86_VENDOR(ENUM, STR)
[X86] Add a def file to CPU vendor, type, and subtype encodings used by Host.cpp Summary: I want to leverage this to clean up some of the code in clang. This will allow us to simplify D39521 which was trying to do some of the same. If we accurately keep the code in Host.cpp synced with new CPUs added to compile-rt/libgcc we should be able to use this file as a proxy for what's implemented in the libraries. The entries for the CPUs recognized by the libraries use separate macros that define additional parameters like the name for __builtin_cpu_is and an alias string for the couple cases where __builtin_cpu_is accepts two different names. All of the macros contain an ARCHNAME that is usually the same as the __builtin_cpu_is string, but sometimes isn't. This represents the name recognized by X86.td and -march. I'm following the precedent set by ARM and AArch64 and adding this information to lib/Support/TargetParser.cpp Reviewers: erichkeane, echristo, asbirlea Reviewed By: echristo Subscribers: llvm-commits, aemerson, kristof.beyls Differential Revision: https://reviews.llvm.org/D39782 llvm-svn: 317900
2017-11-10 18:10:57 +01:00
#endif
X86_VENDOR(VENDOR_INTEL, "intel")
X86_VENDOR(VENDOR_AMD, "amd")
#undef X86_VENDOR
// This macro is used for cpu types present in compiler-rt/libgcc.
#ifndef X86_CPU_TYPE
[X86] Rename X86_CPU_TYPE_COMPAT_ALIAS/X86_CPU_TYPE_COMPAT/X86_CPU_SUBTYPE_COMPAT macros. NFC Remove _COMPAT. Drop the ARCHNAME. Remove the non-COMPAT versions that are no longer needed. We now only use these macros in places where we need compatibility with libgcc/compiler-rt. So we don't need to call out _COMPAT specifically.
2020-07-13 01:58:27 +02:00
#define X86_CPU_TYPE(ENUM, STR)
[X86] Add a def file to CPU vendor, type, and subtype encodings used by Host.cpp Summary: I want to leverage this to clean up some of the code in clang. This will allow us to simplify D39521 which was trying to do some of the same. If we accurately keep the code in Host.cpp synced with new CPUs added to compile-rt/libgcc we should be able to use this file as a proxy for what's implemented in the libraries. The entries for the CPUs recognized by the libraries use separate macros that define additional parameters like the name for __builtin_cpu_is and an alias string for the couple cases where __builtin_cpu_is accepts two different names. All of the macros contain an ARCHNAME that is usually the same as the __builtin_cpu_is string, but sometimes isn't. This represents the name recognized by X86.td and -march. I'm following the precedent set by ARM and AArch64 and adding this information to lib/Support/TargetParser.cpp Reviewers: erichkeane, echristo, asbirlea Reviewed By: echristo Subscribers: llvm-commits, aemerson, kristof.beyls Differential Revision: https://reviews.llvm.org/D39782 llvm-svn: 317900
2017-11-10 18:10:57 +01:00
#endif
[X86] Separate X86_CPU_TYPE_COMPAT_WITH_ALIAS from X86_CPU_TYPE_COMPAT. NFC Add a separate X86_CPU_TYPE_COMPAT_ALIAS that carries alias string and the enum from X86_CPU_TYPE_COMPAT.
2020-06-03 20:57:03 +02:00
[X86] Rename X86_CPU_TYPE_COMPAT_ALIAS/X86_CPU_TYPE_COMPAT/X86_CPU_SUBTYPE_COMPAT macros. NFC Remove _COMPAT. Drop the ARCHNAME. Remove the non-COMPAT versions that are no longer needed. We now only use these macros in places where we need compatibility with libgcc/compiler-rt. So we don't need to call out _COMPAT specifically.
2020-07-13 01:58:27 +02:00
#ifndef X86_CPU_TYPE_ALIAS
#define X86_CPU_TYPE_ALIAS(ENUM, STR)
[X86] Separate X86_CPU_TYPE_COMPAT_WITH_ALIAS from X86_CPU_TYPE_COMPAT. NFC Add a separate X86_CPU_TYPE_COMPAT_ALIAS that carries alias string and the enum from X86_CPU_TYPE_COMPAT.
2020-06-03 20:57:03 +02:00
#endif
[X86] Rename X86_CPU_TYPE_COMPAT_ALIAS/X86_CPU_TYPE_COMPAT/X86_CPU_SUBTYPE_COMPAT macros. NFC Remove _COMPAT. Drop the ARCHNAME. Remove the non-COMPAT versions that are no longer needed. We now only use these macros in places where we need compatibility with libgcc/compiler-rt. So we don't need to call out _COMPAT specifically.
2020-07-13 01:58:27 +02:00
// This list must match what is implemented in libgcc and compilert-rt. Clang
// uses this to know how to implement __builtin_cpu_is.
X86_CPU_TYPE(INTEL_BONNELL, "bonnell")
X86_CPU_TYPE(INTEL_CORE2, "core2")
X86_CPU_TYPE(INTEL_COREI7, "corei7")
X86_CPU_TYPE(AMDFAM10H, "amdfam10h")
X86_CPU_TYPE(AMDFAM15H, "amdfam15h")
X86_CPU_TYPE(INTEL_SILVERMONT, "silvermont")
X86_CPU_TYPE(INTEL_KNL, "knl")
X86_CPU_TYPE(AMD_BTVER1, "btver1")
X86_CPU_TYPE(AMD_BTVER2, "btver2")
X86_CPU_TYPE(AMDFAM17H, "amdfam17h")
X86_CPU_TYPE(INTEL_KNM, "knm")
X86_CPU_TYPE(INTEL_GOLDMONT, "goldmont")
X86_CPU_TYPE(INTEL_GOLDMONT_PLUS, "goldmont-plus")
X86_CPU_TYPE(INTEL_TREMONT, "tremont")
[X86] Autodetect znver3
2020-12-05 19:07:09 +01:00
X86_CPU_TYPE(AMDFAM19H, "amdfam19h")
[X86] Separate X86_CPU_TYPE_COMPAT_WITH_ALIAS from X86_CPU_TYPE_COMPAT. NFC Add a separate X86_CPU_TYPE_COMPAT_ALIAS that carries alias string and the enum from X86_CPU_TYPE_COMPAT.
2020-06-03 20:57:03 +02:00
// Alternate names supported by __builtin_cpu_is and target multiversioning.
[X86] Rename X86_CPU_TYPE_COMPAT_ALIAS/X86_CPU_TYPE_COMPAT/X86_CPU_SUBTYPE_COMPAT macros. NFC Remove _COMPAT. Drop the ARCHNAME. Remove the non-COMPAT versions that are no longer needed. We now only use these macros in places where we need compatibility with libgcc/compiler-rt. So we don't need to call out _COMPAT specifically.
2020-07-13 01:58:27 +02:00
X86_CPU_TYPE_ALIAS(INTEL_BONNELL, "atom")
X86_CPU_TYPE_ALIAS(AMDFAM10H, "amdfam10")
X86_CPU_TYPE_ALIAS(AMDFAM15H, "amdfam15")
X86_CPU_TYPE_ALIAS(INTEL_SILVERMONT, "slm")
[X86] Separate X86_CPU_TYPE_COMPAT_WITH_ALIAS from X86_CPU_TYPE_COMPAT. NFC Add a separate X86_CPU_TYPE_COMPAT_ALIAS that carries alias string and the enum from X86_CPU_TYPE_COMPAT.
2020-06-03 20:57:03 +02:00
[X86] Rename X86_CPU_TYPE_COMPAT_ALIAS/X86_CPU_TYPE_COMPAT/X86_CPU_SUBTYPE_COMPAT macros. NFC Remove _COMPAT. Drop the ARCHNAME. Remove the non-COMPAT versions that are no longer needed. We now only use these macros in places where we need compatibility with libgcc/compiler-rt. So we don't need to call out _COMPAT specifically.
2020-07-13 01:58:27 +02:00
#undef X86_CPU_TYPE_ALIAS
[X86] Add a def file to CPU vendor, type, and subtype encodings used by Host.cpp Summary: I want to leverage this to clean up some of the code in clang. This will allow us to simplify D39521 which was trying to do some of the same. If we accurately keep the code in Host.cpp synced with new CPUs added to compile-rt/libgcc we should be able to use this file as a proxy for what's implemented in the libraries. The entries for the CPUs recognized by the libraries use separate macros that define additional parameters like the name for __builtin_cpu_is and an alias string for the couple cases where __builtin_cpu_is accepts two different names. All of the macros contain an ARCHNAME that is usually the same as the __builtin_cpu_is string, but sometimes isn't. This represents the name recognized by X86.td and -march. I'm following the precedent set by ARM and AArch64 and adding this information to lib/Support/TargetParser.cpp Reviewers: erichkeane, echristo, asbirlea Reviewed By: echristo Subscribers: llvm-commits, aemerson, kristof.beyls Differential Revision: https://reviews.llvm.org/D39782 llvm-svn: 317900
2017-11-10 18:10:57 +01:00
#undef X86_CPU_TYPE
// This macro is used for cpu subtypes present in compiler-rt/libgcc.
#ifndef X86_CPU_SUBTYPE
[X86] Rename X86_CPU_TYPE_COMPAT_ALIAS/X86_CPU_TYPE_COMPAT/X86_CPU_SUBTYPE_COMPAT macros. NFC Remove _COMPAT. Drop the ARCHNAME. Remove the non-COMPAT versions that are no longer needed. We now only use these macros in places where we need compatibility with libgcc/compiler-rt. So we don't need to call out _COMPAT specifically.
2020-07-13 01:58:27 +02:00
#define X86_CPU_SUBTYPE(ENUM, STR)
[X86] Add a def file to CPU vendor, type, and subtype encodings used by Host.cpp Summary: I want to leverage this to clean up some of the code in clang. This will allow us to simplify D39521 which was trying to do some of the same. If we accurately keep the code in Host.cpp synced with new CPUs added to compile-rt/libgcc we should be able to use this file as a proxy for what's implemented in the libraries. The entries for the CPUs recognized by the libraries use separate macros that define additional parameters like the name for __builtin_cpu_is and an alias string for the couple cases where __builtin_cpu_is accepts two different names. All of the macros contain an ARCHNAME that is usually the same as the __builtin_cpu_is string, but sometimes isn't. This represents the name recognized by X86.td and -march. I'm following the precedent set by ARM and AArch64 and adding this information to lib/Support/TargetParser.cpp Reviewers: erichkeane, echristo, asbirlea Reviewed By: echristo Subscribers: llvm-commits, aemerson, kristof.beyls Differential Revision: https://reviews.llvm.org/D39782 llvm-svn: 317900
2017-11-10 18:10:57 +01:00
#endif
[X86] Rename X86_CPU_TYPE_COMPAT_ALIAS/X86_CPU_TYPE_COMPAT/X86_CPU_SUBTYPE_COMPAT macros. NFC Remove _COMPAT. Drop the ARCHNAME. Remove the non-COMPAT versions that are no longer needed. We now only use these macros in places where we need compatibility with libgcc/compiler-rt. So we don't need to call out _COMPAT specifically.
2020-07-13 01:58:27 +02:00
// This list must match what is implemented in libgcc and compilert-rt. Clang
// uses this to know how to implement __builtin_cpu_is.
X86_CPU_SUBTYPE(INTEL_COREI7_NEHALEM, "nehalem")
X86_CPU_SUBTYPE(INTEL_COREI7_WESTMERE, "westmere")
X86_CPU_SUBTYPE(INTEL_COREI7_SANDYBRIDGE, "sandybridge")
X86_CPU_SUBTYPE(AMDFAM10H_BARCELONA, "barcelona")
X86_CPU_SUBTYPE(AMDFAM10H_SHANGHAI, "shanghai")
X86_CPU_SUBTYPE(AMDFAM10H_ISTANBUL, "istanbul")
X86_CPU_SUBTYPE(AMDFAM15H_BDVER1, "bdver1")
X86_CPU_SUBTYPE(AMDFAM15H_BDVER2, "bdver2")
X86_CPU_SUBTYPE(AMDFAM15H_BDVER3, "bdver3")
X86_CPU_SUBTYPE(AMDFAM15H_BDVER4, "bdver4")
X86_CPU_SUBTYPE(AMDFAM17H_ZNVER1, "znver1")
X86_CPU_SUBTYPE(INTEL_COREI7_IVYBRIDGE, "ivybridge")
X86_CPU_SUBTYPE(INTEL_COREI7_HASWELL, "haswell")
X86_CPU_SUBTYPE(INTEL_COREI7_BROADWELL, "broadwell")
X86_CPU_SUBTYPE(INTEL_COREI7_SKYLAKE, "skylake")
X86_CPU_SUBTYPE(INTEL_COREI7_SKYLAKE_AVX512, "skylake-avx512")
X86_CPU_SUBTYPE(INTEL_COREI7_CANNONLAKE, "cannonlake")
X86_CPU_SUBTYPE(INTEL_COREI7_ICELAKE_CLIENT, "icelake-client")
X86_CPU_SUBTYPE(INTEL_COREI7_ICELAKE_SERVER, "icelake-server")
X86_CPU_SUBTYPE(AMDFAM17H_ZNVER2, "znver2")
X86_CPU_SUBTYPE(INTEL_COREI7_CASCADELAKE, "cascadelake")
X86_CPU_SUBTYPE(INTEL_COREI7_TIGERLAKE, "tigerlake")
X86_CPU_SUBTYPE(INTEL_COREI7_COOPERLAKE, "cooperlake")
[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 06:27:02 +02:00
X86_CPU_SUBTYPE(INTEL_COREI7_SAPPHIRERAPIDS, "sapphirerapids")
[X86] Add a stub for Intel's alderlake. No scheduling, no autodetection.
2020-10-24 18:00:33 +02:00
X86_CPU_SUBTYPE(INTEL_COREI7_ALDERLAKE, "alderlake")
[X86] Autodetect znver3
2020-12-05 19:07:09 +01:00
X86_CPU_SUBTYPE(AMDFAM19H_ZNVER3, "znver3")
[X86] Support -march=rocketlake Reviewed By: skan, craig.topper, MaskRay Differential Revision: https://reviews.llvm.org/D100085
2021-04-13 03:24:34 +02:00
X86_CPU_SUBTYPE(INTEL_COREI7_ROCKETLAKE, "rocketlake")
[X86] Add a def file to CPU vendor, type, and subtype encodings used by Host.cpp Summary: I want to leverage this to clean up some of the code in clang. This will allow us to simplify D39521 which was trying to do some of the same. If we accurately keep the code in Host.cpp synced with new CPUs added to compile-rt/libgcc we should be able to use this file as a proxy for what's implemented in the libraries. The entries for the CPUs recognized by the libraries use separate macros that define additional parameters like the name for __builtin_cpu_is and an alias string for the couple cases where __builtin_cpu_is accepts two different names. All of the macros contain an ARCHNAME that is usually the same as the __builtin_cpu_is string, but sometimes isn't. This represents the name recognized by X86.td and -march. I'm following the precedent set by ARM and AArch64 and adding this information to lib/Support/TargetParser.cpp Reviewers: erichkeane, echristo, asbirlea Reviewed By: echristo Subscribers: llvm-commits, aemerson, kristof.beyls Differential Revision: https://reviews.llvm.org/D39782 llvm-svn: 317900
2017-11-10 18:10:57 +01:00
#undef X86_CPU_SUBTYPE
[X86] Move the information about the feature bits used by compiler-rt and shared by Host.cpp to a .def file and TargetParser.h so clang can make use of it. Since we keep Host.cpp and compiler-rt relatively in sync, clang can use this information as a proxy. llvm-svn: 318814
2017-11-22 00:36:42 +01:00
// This macro is used for cpu types present in compiler-rt/libgcc.
#ifndef X86_FEATURE_COMPAT
[X86] Move frontend CPU feature initialization to a look up table based implementation. NFCI This replaces the switch statement implementation in the clang's X86.cpp with a lookup table in X86TargetParser.cpp. I've used constexpr and copy of the FeatureBitset from SubtargetFeature.h to store the features in a lookup table. After the lookup the bitset is translated into strings for use by the rest of the frontend code. I had to modify the implementation of the FeatureBitset to avoid bugs in gcc 5.5 constexpr handling. It seems to not like the same array entry to be used on the left side and right hand side of an assignment or &= or |=. I've also used uint32_t instead of uint64_t and sized based on the X86::CPU_FEATURE_MAX. I've initialized the features for different CPUs outside of the table so that we can express inheritance in an adhoc way. This was one of the big limitations of the switch and we had resorted to labels and gotos. Differential Revision: https://reviews.llvm.org/D82731
2020-06-30 20:59:03 +02:00
#define X86_FEATURE_COMPAT(ENUM, STR) X86_FEATURE(ENUM, STR)
[X86] Move the information about the feature bits used by compiler-rt and shared by Host.cpp to a .def file and TargetParser.h so clang can make use of it. Since we keep Host.cpp and compiler-rt relatively in sync, clang can use this information as a proxy. llvm-svn: 318814
2017-11-22 00:36:42 +01:00
#endif
#ifndef X86_FEATURE
[X86] Move frontend CPU feature initialization to a look up table based implementation. NFCI This replaces the switch statement implementation in the clang's X86.cpp with a lookup table in X86TargetParser.cpp. I've used constexpr and copy of the FeatureBitset from SubtargetFeature.h to store the features in a lookup table. After the lookup the bitset is translated into strings for use by the rest of the frontend code. I had to modify the implementation of the FeatureBitset to avoid bugs in gcc 5.5 constexpr handling. It seems to not like the same array entry to be used on the left side and right hand side of an assignment or &= or |=. I've also used uint32_t instead of uint64_t and sized based on the X86::CPU_FEATURE_MAX. I've initialized the features for different CPUs outside of the table so that we can express inheritance in an adhoc way. This was one of the big limitations of the switch and we had resorted to labels and gotos. Differential Revision: https://reviews.llvm.org/D82731
2020-06-30 20:59:03 +02:00
#define X86_FEATURE(ENUM, STR)
[X86] Move the information about the feature bits used by compiler-rt and shared by Host.cpp to a .def file and TargetParser.h so clang can make use of it. Since we keep Host.cpp and compiler-rt relatively in sync, clang can use this information as a proxy. llvm-svn: 318814
2017-11-22 00:36:42 +01:00
#endif
[X86] Remove encoding value from the X86_FEATURE and X86_FEATURE_COMPAT macro. NFCI This was orignally done so we could separate the compatibility values and the llvm internal only features into a separate entries in the feature array. This was needed when we explicitly had to convert the feature into the proper 32-bit chunk at every reference and we didn't want things moving around. Now everything is in an array and we have helper funtions or macros to convert encoding to index. So we renumbering is no longer an issue.
2020-06-22 05:20:04 +02:00
[X86] Move frontend CPU feature initialization to a look up table based implementation. NFCI This replaces the switch statement implementation in the clang's X86.cpp with a lookup table in X86TargetParser.cpp. I've used constexpr and copy of the FeatureBitset from SubtargetFeature.h to store the features in a lookup table. After the lookup the bitset is translated into strings for use by the rest of the frontend code. I had to modify the implementation of the FeatureBitset to avoid bugs in gcc 5.5 constexpr handling. It seems to not like the same array entry to be used on the left side and right hand side of an assignment or &= or |=. I've also used uint32_t instead of uint64_t and sized based on the X86::CPU_FEATURE_MAX. I've initialized the features for different CPUs outside of the table so that we can express inheritance in an adhoc way. This was one of the big limitations of the switch and we had resorted to labels and gotos. Differential Revision: https://reviews.llvm.org/D82731
2020-06-30 20:59:03 +02:00
X86_FEATURE_COMPAT(CMOV, "cmov")
X86_FEATURE_COMPAT(MMX, "mmx")
X86_FEATURE_COMPAT(POPCNT, "popcnt")
X86_FEATURE_COMPAT(SSE, "sse")
X86_FEATURE_COMPAT(SSE2, "sse2")
X86_FEATURE_COMPAT(SSE3, "sse3")
X86_FEATURE_COMPAT(SSSE3, "ssse3")
X86_FEATURE_COMPAT(SSE4_1, "sse4.1")
X86_FEATURE_COMPAT(SSE4_2, "sse4.2")
X86_FEATURE_COMPAT(AVX, "avx")
X86_FEATURE_COMPAT(AVX2, "avx2")
X86_FEATURE_COMPAT(SSE4_A, "sse4a")
X86_FEATURE_COMPAT(FMA4, "fma4")
X86_FEATURE_COMPAT(XOP, "xop")
X86_FEATURE_COMPAT(FMA, "fma")
X86_FEATURE_COMPAT(AVX512F, "avx512f")
X86_FEATURE_COMPAT(BMI, "bmi")
X86_FEATURE_COMPAT(BMI2, "bmi2")
X86_FEATURE_COMPAT(AES, "aes")
X86_FEATURE_COMPAT(PCLMUL, "pclmul")
X86_FEATURE_COMPAT(AVX512VL, "avx512vl")
X86_FEATURE_COMPAT(AVX512BW, "avx512bw")
X86_FEATURE_COMPAT(AVX512DQ, "avx512dq")
X86_FEATURE_COMPAT(AVX512CD, "avx512cd")
X86_FEATURE_COMPAT(AVX512ER, "avx512er")
X86_FEATURE_COMPAT(AVX512PF, "avx512pf")
X86_FEATURE_COMPAT(AVX512VBMI, "avx512vbmi")
X86_FEATURE_COMPAT(AVX512IFMA, "avx512ifma")
X86_FEATURE_COMPAT(AVX5124VNNIW, "avx5124vnniw")
X86_FEATURE_COMPAT(AVX5124FMAPS, "avx5124fmaps")
X86_FEATURE_COMPAT(AVX512VPOPCNTDQ, "avx512vpopcntdq")
X86_FEATURE_COMPAT(AVX512VBMI2, "avx512vbmi2")
X86_FEATURE_COMPAT(GFNI, "gfni")
X86_FEATURE_COMPAT(VPCLMULQDQ, "vpclmulqdq")
X86_FEATURE_COMPAT(AVX512VNNI, "avx512vnni")
X86_FEATURE_COMPAT(AVX512BITALG, "avx512bitalg")
X86_FEATURE_COMPAT(AVX512BF16, "avx512bf16")
X86_FEATURE_COMPAT(AVX512VP2INTERSECT, "avx512vp2intersect")
[X86] Move the information about the feature bits used by compiler-rt and shared by Host.cpp to a .def file and TargetParser.h so clang can make use of it. Since we keep Host.cpp and compiler-rt relatively in sync, clang can use this information as a proxy. llvm-svn: 318814
2017-11-22 00:36:42 +01:00
// Features below here are not in libgcc/compiler-rt.
[X86] Move frontend CPU feature initialization to a look up table based implementation. NFCI This replaces the switch statement implementation in the clang's X86.cpp with a lookup table in X86TargetParser.cpp. I've used constexpr and copy of the FeatureBitset from SubtargetFeature.h to store the features in a lookup table. After the lookup the bitset is translated into strings for use by the rest of the frontend code. I had to modify the implementation of the FeatureBitset to avoid bugs in gcc 5.5 constexpr handling. It seems to not like the same array entry to be used on the left side and right hand side of an assignment or &= or |=. I've also used uint32_t instead of uint64_t and sized based on the X86::CPU_FEATURE_MAX. I've initialized the features for different CPUs outside of the table so that we can express inheritance in an adhoc way. This was one of the big limitations of the switch and we had resorted to labels and gotos. Differential Revision: https://reviews.llvm.org/D82731
2020-06-30 20:59:03 +02:00
X86_FEATURE (3DNOW, "3dnow")
X86_FEATURE (3DNOWA, "3dnowa")
[X86] Add 64bit and retpoline-external-thunk to list of featuers in X86TargetParser.def. '64bit' shows up from -march=native on 64-bit capable CPUs. 'retpoline-eternal-thunk' isn't a real feature but shows up when -mretpoline-external-thunk is passed to clang.
2020-07-07 09:27:50 +02:00
X86_FEATURE (64BIT, "64bit")
[X86] Move frontend CPU feature initialization to a look up table based implementation. NFCI This replaces the switch statement implementation in the clang's X86.cpp with a lookup table in X86TargetParser.cpp. I've used constexpr and copy of the FeatureBitset from SubtargetFeature.h to store the features in a lookup table. After the lookup the bitset is translated into strings for use by the rest of the frontend code. I had to modify the implementation of the FeatureBitset to avoid bugs in gcc 5.5 constexpr handling. It seems to not like the same array entry to be used on the left side and right hand side of an assignment or &= or |=. I've also used uint32_t instead of uint64_t and sized based on the X86::CPU_FEATURE_MAX. I've initialized the features for different CPUs outside of the table so that we can express inheritance in an adhoc way. This was one of the big limitations of the switch and we had resorted to labels and gotos. Differential Revision: https://reviews.llvm.org/D82731
2020-06-30 20:59:03 +02:00
X86_FEATURE (ADX, "adx")
[X86] Move the feature dependency handling in X86TargetInfo::setFeatureEnabledImpl to a table based lookup in X86TargetParser.cpp Previously we had to specify the forward and backwards feature dependencies separately which was error prone. And as dependencies have gotten more complex it was hard to be sure the transitive dependencies were handled correctly. The way it was written was also not super readable. This patch replaces everything with a table that lists what features a feature is dependent on directly. Then we can recursively walk through the table to find the transitive dependencies. This is largely based on how we handle subtarget features in the MC layer from the tablegen descriptions. Differential Revision: https://reviews.llvm.org/D83273
2020-07-07 07:47:54 +02:00
X86_FEATURE (AMX_BF16, "amx-bf16")
X86_FEATURE (AMX_INT8, "amx-int8")
X86_FEATURE (AMX_TILE, "amx-tile")
[X86] Move frontend CPU feature initialization to a look up table based implementation. NFCI This replaces the switch statement implementation in the clang's X86.cpp with a lookup table in X86TargetParser.cpp. I've used constexpr and copy of the FeatureBitset from SubtargetFeature.h to store the features in a lookup table. After the lookup the bitset is translated into strings for use by the rest of the frontend code. I had to modify the implementation of the FeatureBitset to avoid bugs in gcc 5.5 constexpr handling. It seems to not like the same array entry to be used on the left side and right hand side of an assignment or &= or |=. I've also used uint32_t instead of uint64_t and sized based on the X86::CPU_FEATURE_MAX. I've initialized the features for different CPUs outside of the table so that we can express inheritance in an adhoc way. This was one of the big limitations of the switch and we had resorted to labels and gotos. Differential Revision: https://reviews.llvm.org/D82731
2020-06-30 20:59:03 +02:00
X86_FEATURE (CLDEMOTE, "cldemote")
X86_FEATURE (CLFLUSHOPT, "clflushopt")
X86_FEATURE (CLWB, "clwb")
X86_FEATURE (CLZERO, "clzero")
X86_FEATURE (CMPXCHG16B, "cx16")
X86_FEATURE (CMPXCHG8B, "cx8")
X86_FEATURE (ENQCMD, "enqcmd")
X86_FEATURE (F16C, "f16c")
X86_FEATURE (FSGSBASE, "fsgsbase")
X86_FEATURE (FXSR, "fxsr")
X86_FEATURE (INVPCID, "invpcid")
[X86] Support Intel Key Locker Key Locker provides a mechanism to encrypt and decrypt data with an AES key without having access to the raw key value by converting AES keys into “handles”. These handles can be used to perform the same encryption and decryption operations as the original AES keys, but they only work on the current system and only until they are revoked. If software revokes Key Locker handles (e.g., on a reboot), then any previous handles can no longer be used. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D88398
2020-09-30 12:01:15 +02:00
X86_FEATURE (KL, "kl")
X86_FEATURE (WIDEKL, "widekl")
[X86] Move frontend CPU feature initialization to a look up table based implementation. NFCI This replaces the switch statement implementation in the clang's X86.cpp with a lookup table in X86TargetParser.cpp. I've used constexpr and copy of the FeatureBitset from SubtargetFeature.h to store the features in a lookup table. After the lookup the bitset is translated into strings for use by the rest of the frontend code. I had to modify the implementation of the FeatureBitset to avoid bugs in gcc 5.5 constexpr handling. It seems to not like the same array entry to be used on the left side and right hand side of an assignment or &= or |=. I've also used uint32_t instead of uint64_t and sized based on the X86::CPU_FEATURE_MAX. I've initialized the features for different CPUs outside of the table so that we can express inheritance in an adhoc way. This was one of the big limitations of the switch and we had resorted to labels and gotos. Differential Revision: https://reviews.llvm.org/D82731
2020-06-30 20:59:03 +02:00
X86_FEATURE (LWP, "lwp")
X86_FEATURE (LZCNT, "lzcnt")
X86_FEATURE (MOVBE, "movbe")
X86_FEATURE (MOVDIR64B, "movdir64b")
X86_FEATURE (MOVDIRI, "movdiri")
X86_FEATURE (MWAITX, "mwaitx")
X86_FEATURE (PCONFIG, "pconfig")
X86_FEATURE (PKU, "pku")
X86_FEATURE (PREFETCHWT1, "prefetchwt1")
X86_FEATURE (PRFCHW, "prfchw")
X86_FEATURE (PTWRITE, "ptwrite")
X86_FEATURE (RDPID, "rdpid")
X86_FEATURE (RDRND, "rdrnd")
X86_FEATURE (RDSEED, "rdseed")
X86_FEATURE (RTM, "rtm")
X86_FEATURE (SAHF, "sahf")
X86_FEATURE (SERIALIZE, "serialize")
X86_FEATURE (SGX, "sgx")
X86_FEATURE (SHA, "sha")
X86_FEATURE (SHSTK, "shstk")
X86_FEATURE (TBM, "tbm")
X86_FEATURE (TSXLDTRK, "tsxldtrk")
[X86] Add User Interrupts(UINTR) instructions For more details about these instructions, please refer to the latest ISE document: https://software.intel.com/en-us/download/intel-architecture-instruction-set-extensions-programming-reference. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D89301
2020-10-22 10:46:07 +02:00
X86_FEATURE (UINTR, "uintr")
[X86] Move frontend CPU feature initialization to a look up table based implementation. NFCI This replaces the switch statement implementation in the clang's X86.cpp with a lookup table in X86TargetParser.cpp. I've used constexpr and copy of the FeatureBitset from SubtargetFeature.h to store the features in a lookup table. After the lookup the bitset is translated into strings for use by the rest of the frontend code. I had to modify the implementation of the FeatureBitset to avoid bugs in gcc 5.5 constexpr handling. It seems to not like the same array entry to be used on the left side and right hand side of an assignment or &= or |=. I've also used uint32_t instead of uint64_t and sized based on the X86::CPU_FEATURE_MAX. I've initialized the features for different CPUs outside of the table so that we can express inheritance in an adhoc way. This was one of the big limitations of the switch and we had resorted to labels and gotos. Differential Revision: https://reviews.llvm.org/D82731
2020-06-30 20:59:03 +02:00
X86_FEATURE (VAES, "vaes")
[X86] Move the feature dependency handling in X86TargetInfo::setFeatureEnabledImpl to a table based lookup in X86TargetParser.cpp Previously we had to specify the forward and backwards feature dependencies separately which was error prone. And as dependencies have gotten more complex it was hard to be sure the transitive dependencies were handled correctly. The way it was written was also not super readable. This patch replaces everything with a table that lists what features a feature is dependent on directly. Then we can recursively walk through the table to find the transitive dependencies. This is largely based on how we handle subtarget features in the MC layer from the tablegen descriptions. Differential Revision: https://reviews.llvm.org/D83273
2020-07-07 07:47:54 +02:00
X86_FEATURE (VZEROUPPER, "vzeroupper")
[X86] Move frontend CPU feature initialization to a look up table based implementation. NFCI This replaces the switch statement implementation in the clang's X86.cpp with a lookup table in X86TargetParser.cpp. I've used constexpr and copy of the FeatureBitset from SubtargetFeature.h to store the features in a lookup table. After the lookup the bitset is translated into strings for use by the rest of the frontend code. I had to modify the implementation of the FeatureBitset to avoid bugs in gcc 5.5 constexpr handling. It seems to not like the same array entry to be used on the left side and right hand side of an assignment or &= or |=. I've also used uint32_t instead of uint64_t and sized based on the X86::CPU_FEATURE_MAX. I've initialized the features for different CPUs outside of the table so that we can express inheritance in an adhoc way. This was one of the big limitations of the switch and we had resorted to labels and gotos. Differential Revision: https://reviews.llvm.org/D82731
2020-06-30 20:59:03 +02:00
X86_FEATURE (WAITPKG, "waitpkg")
X86_FEATURE (WBNOINVD, "wbnoinvd")
X86_FEATURE (X87, "x87")
X86_FEATURE (XSAVE, "xsave")
X86_FEATURE (XSAVEC, "xsavec")
X86_FEATURE (XSAVEOPT, "xsaveopt")
X86_FEATURE (XSAVES, "xsaves")
[X86] Add HRESET instruction. For more details about these instructions, please refer to the latest ISE document: https://software.intel.com/en-us/download/intel-architecture-instruction-set-extensions-programming-reference. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D89102
2020-10-13 02:42:46 +02:00
X86_FEATURE (HRESET, "hreset")
[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 05:58:05 +01:00
X86_FEATURE (AVXVNNI, "avxvnni")
[X86] Move the feature dependency handling in X86TargetInfo::setFeatureEnabledImpl to a table based lookup in X86TargetParser.cpp Previously we had to specify the forward and backwards feature dependencies separately which was error prone. And as dependencies have gotten more complex it was hard to be sure the transitive dependencies were handled correctly. The way it was written was also not super readable. This patch replaces everything with a table that lists what features a feature is dependent on directly. Then we can recursively walk through the table to find the transitive dependencies. This is largely based on how we handle subtarget features in the MC layer from the tablegen descriptions. Differential Revision: https://reviews.llvm.org/D83273
2020-07-07 07:47:54 +02:00
// These features aren't really CPU features, but the frontend can set them.
[X86] Add 64bit and retpoline-external-thunk to list of featuers in X86TargetParser.def. '64bit' shows up from -march=native on 64-bit capable CPUs. 'retpoline-eternal-thunk' isn't a real feature but shows up when -mretpoline-external-thunk is passed to clang.
2020-07-07 09:27:50 +02:00
X86_FEATURE (RETPOLINE_EXTERNAL_THUNK, "retpoline-external-thunk")
[X86] Move the feature dependency handling in X86TargetInfo::setFeatureEnabledImpl to a table based lookup in X86TargetParser.cpp Previously we had to specify the forward and backwards feature dependencies separately which was error prone. And as dependencies have gotten more complex it was hard to be sure the transitive dependencies were handled correctly. The way it was written was also not super readable. This patch replaces everything with a table that lists what features a feature is dependent on directly. Then we can recursively walk through the table to find the transitive dependencies. This is largely based on how we handle subtarget features in the MC layer from the tablegen descriptions. Differential Revision: https://reviews.llvm.org/D83273
2020-07-07 07:47:54 +02:00
X86_FEATURE (RETPOLINE_INDIRECT_BRANCHES, "retpoline-indirect-branches")
X86_FEATURE (RETPOLINE_INDIRECT_CALLS, "retpoline-indirect-calls")
X86_FEATURE (LVI_CFI, "lvi-cfi")
X86_FEATURE (LVI_LOAD_HARDENING, "lvi-load-hardening")
[X86] Move the information about the feature bits used by compiler-rt and shared by Host.cpp to a .def file and TargetParser.h so clang can make use of it. Since we keep Host.cpp and compiler-rt relatively in sync, clang can use this information as a proxy. llvm-svn: 318814
2017-11-22 00:36:42 +01:00
#undef X86_FEATURE_COMPAT
#undef X86_FEATURE
Reference in New Issue Copy Permalink