maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/lib/Basic/Targets/AArch64.cpp

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

900 lines
29 KiB
C++
Raw Normal View History

Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
//===--- AArch64.cpp - Implement AArch64 target feature support -----------===//
//
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 16:50:56 +08: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
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
//
//===----------------------------------------------------------------------===//
//
// This file implements AArch64 TargetInfo objects.
//
//===----------------------------------------------------------------------===//
#include "AArch64.h"
[clang] Move branch-protection from CodeGenOptions to LangOptions Summary: Reason: the option has an effect on preprocessing. Also see thread: http://lists.llvm.org/pipermail/cfe-dev/2020-March/065014.html Reviewers: chill, efriedma Reviewed By: efriedma Subscribers: efriedma, danielkiss, cfe-commits, kristof.beyls Tags: #clang Differential Revision: https://reviews.llvm.org/D77131
2020-04-02 16:11:01 +08:00
#include "clang/Basic/LangOptions.h"
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
#include "clang/Basic/TargetBuiltins.h"
#include "clang/Basic/TargetInfo.h"
#include "llvm/ADT/ArrayRef.h"
Driver: hoist the `wchar_t` handling to the driver Move the logic for determining the `wchar_t` type information into the driver. Rather than passing the single bit of information of `-fshort-wchar` indicate to the frontend the desired type of `wchar_t` through a new `-cc1` option of `-fwchar-type` and indicate the signedness through `-f{,no-}signed-wchar`. This replicates the current logic which was spread throughout Basic into the `RenderCharacterOptions`. Most of the changes to the tests are to ensure that the frontend uses the correct type. Add a new test set under `test/Driver/wchar_t.c` to ensure that we calculate the proper types for the various cases. llvm-svn: 315126
2017-10-07 07:09:55 +08:00
#include "llvm/ADT/StringExtras.h"
Implement target(branch-protection) attribute for AArch64 This patch implements `__attribute__((target("branch-protection=...")))` in a manner, compatible with the analogous GCC feature: https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/AArch64-Function-Attributes.html#AArch64-Function-Attributes Differential Revision: https://reviews.llvm.org/D68711
2019-11-15 19:34:47 +08:00
#include "llvm/ADT/StringSwitch.h"
#include "llvm/Support/AArch64TargetParser.h"
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
using namespace clang;
using namespace clang::targets;
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
const Builtin::Info AArch64TargetInfo::BuiltinInfo[] = {
#define BUILTIN(ID, TYPE, ATTRS) \
{#ID, TYPE, ATTRS, nullptr, ALL_LANGUAGES, nullptr},
#include "clang/Basic/BuiltinsNEON.def"
Reland D75470 [SVE] Auto-generate builtins and header for svld1. Reworked the patch to avoid sharing a header (SVETypeFlags.h) between include/clang/Basic and utils/TableGen/SveEmitter.cpp. Now the patch generates the enum/flags which is included in TargetBuiltins.h. Also renamed one of the SveEmitter options to be in line with MVE. Summary: This is a first patch in a series for the SveEmitter to generate the arm_sve.h header file and builtins. I've tried my best to strip down this patch as best as I could, but there are still a few changes that are not necessarily exercised by the load intrinsics in this patch, mostly around the SVEType class which has some common logic to represent types from a type and prototype string. I thought it didn't make much sense to remove that from this patch and split it up.
2020-03-18 19:07:20 +08:00
#define BUILTIN(ID, TYPE, ATTRS) \
{#ID, TYPE, ATTRS, nullptr, ALL_LANGUAGES, nullptr},
#include "clang/Basic/BuiltinsSVE.def"
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
#define BUILTIN(ID, TYPE, ATTRS) \
{#ID, TYPE, ATTRS, nullptr, ALL_LANGUAGES, nullptr},
[COFF, ARM64] Add MS builtins __dmb, __dsb, __isb Differential Revision: https://reviews.llvm.org/D38821 llvm-svn: 315567
2017-10-12 15:05:37 +08:00
#define LANGBUILTIN(ID, TYPE, ATTRS, LANG) \
{#ID, TYPE, ATTRS, nullptr, LANG, nullptr},
[AArch64] Define TARGET_HEADER_BUILTIN Without it, the new intrinsics became available for all language variants. This was missed in SVN r337327. llvm-svn: 337352
2018-07-18 14:15:09 +08:00
#define TARGET_HEADER_BUILTIN(ID, TYPE, ATTRS, HEADER, LANGS, FEATURE) \
{#ID, TYPE, ATTRS, HEADER, LANGS, FEATURE},
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
#include "clang/Basic/BuiltinsAArch64.def"
};
AArch64TargetInfo::AArch64TargetInfo(const llvm::Triple &Triple,
const TargetOptions &Opts)
: TargetInfo(Triple), ABI("aapcs") {
Replace getOS() == llvm::Triple::*BSD with isOS*BSD() [NFCI] Replace multiple comparisons of getOS() value with FreeBSD, NetBSD, OpenBSD and DragonFly with matching isOS*BSD() methods. This should improve the consistency of coding style without changing the behavior. Direct getOS() comparisons were left whenever used in switch or switch- like context. Differential Revision: https://reviews.llvm.org/D55916 llvm-svn: 349752
2018-12-20 21:09:30 +08:00
if (getTriple().isOSOpenBSD()) {
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
Int64Type = SignedLongLong;
IntMaxType = SignedLongLong;
} else {
Replace getOS() == llvm::Triple::*BSD with isOS*BSD() [NFCI] Replace multiple comparisons of getOS() value with FreeBSD, NetBSD, OpenBSD and DragonFly with matching isOS*BSD() methods. This should improve the consistency of coding style without changing the behavior. Direct getOS() comparisons were left whenever used in switch or switch- like context. Differential Revision: https://reviews.llvm.org/D55916 llvm-svn: 349752
2018-12-20 21:09:30 +08:00
if (!getTriple().isOSDarwin() && !getTriple().isOSNetBSD())
Driver: hoist the `wchar_t` handling to the driver Move the logic for determining the `wchar_t` type information into the driver. Rather than passing the single bit of information of `-fshort-wchar` indicate to the frontend the desired type of `wchar_t` through a new `-cc1` option of `-fwchar-type` and indicate the signedness through `-f{,no-}signed-wchar`. This replicates the current logic which was spread throughout Basic into the `RenderCharacterOptions`. Most of the changes to the tests are to ensure that the frontend uses the correct type. Add a new test set under `test/Driver/wchar_t.c` to ensure that we calculate the proper types for the various cases. llvm-svn: 315126
2017-10-07 07:09:55 +08:00
WCharType = UnsignedInt;
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
Int64Type = SignedLong;
IntMaxType = SignedLong;
}
[ARM] Pass half or i16 types for NEON intrinsics For generating NEON intrinsics, this determines the NEON data type, and whether it should be a half type or an i16 type. I.e., we always pass a half type for AArch64, this hasn't changed, but now also for ARM but only when FullFP16 is enabled, and i16 otherwise. This is intended to be non-functional change, but together with the backend work in D44538 which adds support for f16 vectors, this enables adding the AArch32 FP16 (vector) intrinsics. Differential Revision: https://reviews.llvm.org/D44561 llvm-svn: 327836
2018-03-19 21:22:49 +08:00
// All AArch64 implementations support ARMv8 FP, which makes half a legal type.
HasLegalHalfType = true;
Disable _Float16 for non ARM/SPIR Targets As Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2019-January/129543.html There are problems exposing the _Float16 type on architectures that haven't defined the ABI/ISel for the type yet, so we're temporarily disabling the type and making it opt-in. Differential Revision: https://reviews.llvm.org/D57188 Change-Id: I5db7366dedf1deb9485adb8948b1deb7e612a736 llvm-svn: 352221
2019-01-26 01:27:57 +08:00
HasFloat16 = true;
Driver: hoist the `wchar_t` handling to the driver Move the logic for determining the `wchar_t` type information into the driver. Rather than passing the single bit of information of `-fshort-wchar` indicate to the frontend the desired type of `wchar_t` through a new `-cc1` option of `-fwchar-type` and indicate the signedness through `-f{,no-}signed-wchar`. This replicates the current logic which was spread throughout Basic into the `RenderCharacterOptions`. Most of the changes to the tests are to ensure that the frontend uses the correct type. Add a new test set under `test/Driver/wchar_t.c` to ensure that we calculate the proper types for the various cases. llvm-svn: 315126
2017-10-07 07:09:55 +08:00
AArch64: add arm64_32 support to Clang.
2018-09-18 17:34:39 +08:00
if (Triple.isArch64Bit())
LongWidth = LongAlign = PointerWidth = PointerAlign = 64;
else
LongWidth = LongAlign = PointerWidth = PointerAlign = 32;
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
MaxVectorAlign = 128;
MaxAtomicInlineWidth = 128;
MaxAtomicPromoteWidth = 128;
LongDoubleWidth = LongDoubleAlign = SuitableAlign = 128;
LongDoubleFormat = &llvm::APFloat::IEEEquad();
[ARM] Add __bf16 as new Bfloat16 C Type Summary: This patch upstreams support for a new storage only bfloat16 C type. This type is used to implement primitive support for bfloat16 data, in line with the Bfloat16 extension of the Armv8.6-a architecture, as detailed here: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a The bfloat type, and its properties are specified in the Arm Architecture Reference Manual: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile In detail this patch: - introduces an opaque, storage-only C-type __bf16, which introduces a new bfloat IR type. This is part of a patch series, starting with command-line and Bfloat16 assembly support. The subsequent patches will upstream intrinsics support for BFloat16, followed by Matrix Multiplication and the remaining Virtualization features of the armv8.6-a architecture. The following people contributed to this patch: - Luke Cheeseman - Momchil Velikov - Alexandros Lamprineas - Luke Geeson - Simon Tatham - Ties Stuij Reviewers: SjoerdMeijer, rjmccall, rsmith, liutianle, RKSimon, craig.topper, jfb, LukeGeeson, fpetrogalli Reviewed By: SjoerdMeijer Subscribers: labrinea, majnemer, asmith, dexonsmith, kristof.beyls, arphaman, danielkiss, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D76077
2020-06-05 07:20:02 +08:00
BFloat16Width = BFloat16Align = 16;
BFloat16Format = &llvm::APFloat::BFloat();
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
// Make __builtin_ms_va_list available.
HasBuiltinMSVaList = true;
Add SVE opaque built-in types This patch adds the SVE built-in types defined by the Procedure Call Standard for the Arm Architecture: https://developer.arm.com/docs/100986/0000 It handles the types in all relevant places that deal with built-in types. At the moment, some of these places bail out with an error, including: (1) trying to generate LLVM IR for the types (2) trying to generate debug info for the types (3) trying to mangle the types using the Microsoft C++ ABI (4) trying to @encode the types in Objective C (1) and (2) are fixed by follow-on patches but (unlike this patch) they deal mostly with target-specific LLVM details, so seemed like a logically separate change. There is currently no spec for (3) and (4), so reporting an error seems like the correct behaviour for now. The intention is that the types will become sizeless types: http://lists.llvm.org/pipermail/cfe-dev/2019-June/062523.html The main purpose of the sizeless type extension is to diagnose impossible or dangerous uses of the types, such as any that would require sizeof to have a meaningful defined value. Until then, the patch sets the alignments of the types to the values specified in the link above. It also sets the sizes of the types to zero, which is chosen to be consistently wrong and shouldn't affect correctly-written code (i.e. code that would compile even with the sizeless type extension). The patch adds the common subset of functionality needed to test the sizeless type extension on the one hand and to provide SVE intrinsic functions on the other. After this patch, the two pieces of work are essentially independent. The patch is based on one by Graham Hunter: https://reviews.llvm.org/D59245 Differential Revision: https://reviews.llvm.org/D62960 llvm-svn: 368413
2019-08-09 16:52:54 +08:00
// Make the SVE types available. Note that this deliberately doesn't
// depend on SveMode, since in principle it should be possible to turn
// SVE on and off within a translation unit. It should also be possible
// to compile the global declaration:
//
// __SVInt8_t *ptr;
//
// even without SVE.
HasAArch64SVETypes = true;
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
// {} in inline assembly are neon specifiers, not assembly variant
// specifiers.
NoAsmVariants = true;
// AAPCS gives rules for bitfields. 7.1.7 says: "The container type
// contributes to the alignment of the containing aggregate in the same way
// a plain (non bit-field) member of that type would, without exception for
// zero-sized or anonymous bit-fields."
assert(UseBitFieldTypeAlignment && "bitfields affect type alignment");
UseZeroLengthBitfieldAlignment = true;
// AArch64 targets default to using the ARM C++ ABI.
TheCXXABI.set(TargetCXXABI::GenericAArch64);
if (Triple.getOS() == llvm::Triple::Linux)
this->MCountName = "\01_mcount";
else if (Triple.getOS() == llvm::Triple::UnknownOS)
this->MCountName =
Opts.EABIVersion == llvm::EABI::GNU ? "\01_mcount" : "mcount";
}
StringRef AArch64TargetInfo::getABI() const { return ABI; }
bool AArch64TargetInfo::setABI(const std::string &Name) {
if (Name != "aapcs" && Name != "darwinpcs")
return false;
ABI = Name;
return true;
}
Implement target(branch-protection) attribute for AArch64 This patch implements `__attribute__((target("branch-protection=...")))` in a manner, compatible with the analogous GCC feature: https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/AArch64-Function-Attributes.html#AArch64-Function-Attributes Differential Revision: https://reviews.llvm.org/D68711
2019-11-15 19:34:47 +08:00
bool AArch64TargetInfo::validateBranchProtection(StringRef Spec,
BranchProtectionInfo &BPI,
StringRef &Err) const {
llvm::AArch64::ParsedBranchProtection PBP;
if (!llvm::AArch64::parseBranchProtection(Spec, PBP, Err))
return false;
BPI.SignReturnAddr =
[clang] Move branch-protection from CodeGenOptions to LangOptions Summary: Reason: the option has an effect on preprocessing. Also see thread: http://lists.llvm.org/pipermail/cfe-dev/2020-March/065014.html Reviewers: chill, efriedma Reviewed By: efriedma Subscribers: efriedma, danielkiss, cfe-commits, kristof.beyls Tags: #clang Differential Revision: https://reviews.llvm.org/D77131
2020-04-02 16:11:01 +08:00
llvm::StringSwitch<LangOptions::SignReturnAddressScopeKind>(PBP.Scope)
.Case("non-leaf", LangOptions::SignReturnAddressScopeKind::NonLeaf)
.Case("all", LangOptions::SignReturnAddressScopeKind::All)
.Default(LangOptions::SignReturnAddressScopeKind::None);
Implement target(branch-protection) attribute for AArch64 This patch implements `__attribute__((target("branch-protection=...")))` in a manner, compatible with the analogous GCC feature: https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/AArch64-Function-Attributes.html#AArch64-Function-Attributes Differential Revision: https://reviews.llvm.org/D68711
2019-11-15 19:34:47 +08:00
if (PBP.Key == "a_key")
[clang] Move branch-protection from CodeGenOptions to LangOptions Summary: Reason: the option has an effect on preprocessing. Also see thread: http://lists.llvm.org/pipermail/cfe-dev/2020-March/065014.html Reviewers: chill, efriedma Reviewed By: efriedma Subscribers: efriedma, danielkiss, cfe-commits, kristof.beyls Tags: #clang Differential Revision: https://reviews.llvm.org/D77131
2020-04-02 16:11:01 +08:00
BPI.SignKey = LangOptions::SignReturnAddressKeyKind::AKey;
Implement target(branch-protection) attribute for AArch64 This patch implements `__attribute__((target("branch-protection=...")))` in a manner, compatible with the analogous GCC feature: https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/AArch64-Function-Attributes.html#AArch64-Function-Attributes Differential Revision: https://reviews.llvm.org/D68711
2019-11-15 19:34:47 +08:00
else
[clang] Move branch-protection from CodeGenOptions to LangOptions Summary: Reason: the option has an effect on preprocessing. Also see thread: http://lists.llvm.org/pipermail/cfe-dev/2020-March/065014.html Reviewers: chill, efriedma Reviewed By: efriedma Subscribers: efriedma, danielkiss, cfe-commits, kristof.beyls Tags: #clang Differential Revision: https://reviews.llvm.org/D77131
2020-04-02 16:11:01 +08:00
BPI.SignKey = LangOptions::SignReturnAddressKeyKind::BKey;
Implement target(branch-protection) attribute for AArch64 This patch implements `__attribute__((target("branch-protection=...")))` in a manner, compatible with the analogous GCC feature: https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/AArch64-Function-Attributes.html#AArch64-Function-Attributes Differential Revision: https://reviews.llvm.org/D68711
2019-11-15 19:34:47 +08:00
BPI.BranchTargetEnforcement = PBP.BranchTargetEnforcement;
return true;
}
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
bool AArch64TargetInfo::isValidCPUName(StringRef Name) const {
return Name == "generic" ||
Update to use enum classes for various ARM *Kind enums Summary: This updates the relevant Clang parts for the LLVM change D35882. Reviewers: rengolin, chandlerc, javed.absar, rovka Reviewed By: rovka Subscribers: aemerson, cfe-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D35884 llvm-svn: 309289
2017-07-28 00:28:39 +08:00
llvm::AArch64::parseCPUArch(Name) != llvm::AArch64::ArchKind::INVALID;
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
}
bool AArch64TargetInfo::setCPU(const std::string &Name) {
return isValidCPUName(Name);
}
Make march/target-cpu print a note with the list of valid values for ARM When rejecting a march= or target-cpu command line parameter, the message is quite lacking. This patch adds a note that prints all possible values for the current target, if the target supports it. This adds support for the ARM/AArch64 targets (more to come!). Differential Revision: https://reviews.llvm.org/D42978 llvm-svn: 324673
2018-02-09 07:14:15 +08:00
void AArch64TargetInfo::fillValidCPUList(
SmallVectorImpl<StringRef> &Values) const {
llvm::AArch64::fillValidCPUArchList(Values);
}
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
void AArch64TargetInfo::getTargetDefinesARMV81A(const LangOptions &Opts,
MacroBuilder &Builder) const {
Builder.defineMacro("__ARM_FEATURE_QRDMX", "1");
[AArch64] Define __ARM_FEATURE_{CRC32,ATOMICS} This patch implements the definition of __ARM_FEATURE_ATOMICS and fixes the missing definition of __ARM_FEATURE_CRC32 for Armv8.1-A. Differential Revision: https://reviews.llvm.org/D91438
2020-11-13 21:56:43 +08:00
Builder.defineMacro("__ARM_FEATURE_ATOMICS", "1");
Builder.defineMacro("__ARM_FEATURE_CRC32", "1");
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
}
void AArch64TargetInfo::getTargetDefinesARMV82A(const LangOptions &Opts,
MacroBuilder &Builder) const {
// Also include the ARMv8.1 defines
getTargetDefinesARMV81A(Opts, Builder);
}
[AArch64] Implement __jcvt intrinsic from Armv8.3-A The jcvt intrinsic defined in ACLE [1] is available when ARM_FEATURE_JCVT is defined. This change introduces the AArch64 intrinsic, wires it up to the instruction and a new clang builtin function. The __ARM_FEATURE_JCVT macro is now defined when an Armv8.3-A or higher target is used. I've implemented the target detection logic in Clang so that this feature is enabled for architectures from armv8.3-a onwards (so -march=armv8.4-a also enables this, for example). make check-all didn't show any new failures. [1] https://developer.arm.com/docs/101028/latest/data-processing-intrinsics Differential Revision: https://reviews.llvm.org/D64495 llvm-svn: 366197
2019-07-16 17:27:39 +08:00
void AArch64TargetInfo::getTargetDefinesARMV83A(const LangOptions &Opts,
MacroBuilder &Builder) const {
[ARM][AArch64] Complex addition Neon intrinsics for Armv8.3-A Summary: Add support for vcadd_* family of intrinsics. This set of intrinsics is available in Armv8.3-A. The fp16 versions require the FP16 extension, which has been available (opt-in) since Armv8.2-A. Reviewers: t.p.northover Reviewed By: t.p.northover Subscribers: t.p.northover, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D70862
2019-12-02 20:13:04 +08:00
Builder.defineMacro("__ARM_FEATURE_COMPLEX", "1");
[AArch64] Implement __jcvt intrinsic from Armv8.3-A The jcvt intrinsic defined in ACLE [1] is available when ARM_FEATURE_JCVT is defined. This change introduces the AArch64 intrinsic, wires it up to the instruction and a new clang builtin function. The __ARM_FEATURE_JCVT macro is now defined when an Armv8.3-A or higher target is used. I've implemented the target detection logic in Clang so that this feature is enabled for architectures from armv8.3-a onwards (so -march=armv8.4-a also enables this, for example). make check-all didn't show any new failures. [1] https://developer.arm.com/docs/101028/latest/data-processing-intrinsics Differential Revision: https://reviews.llvm.org/D64495 llvm-svn: 366197
2019-07-16 17:27:39 +08:00
Builder.defineMacro("__ARM_FEATURE_JCVT", "1");
// Also include the Armv8.2 defines
getTargetDefinesARMV82A(Opts, Builder);
}
void AArch64TargetInfo::getTargetDefinesARMV84A(const LangOptions &Opts,
MacroBuilder &Builder) const {
// Also include the Armv8.3 defines
getTargetDefinesARMV83A(Opts, Builder);
}
void AArch64TargetInfo::getTargetDefinesARMV85A(const LangOptions &Opts,
MacroBuilder &Builder) const {
// Also include the Armv8.4 defines
getTargetDefinesARMV84A(Opts, Builder);
}
[PATCH] [ARM] ARMv8.6-a command-line + BFloat16 Asm Support Summary: This patch introduces command-line support for the Armv8.6-a architecture and assembly support for BFloat16. Details can be found https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a in addition to the GCC patch for the 8..6-a CLI: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-11/msg02647.html In detail this patch - march options for armv8.6-a - BFloat16 assembly This is part of a patch series, starting with command-line and Bfloat16 assembly support. The subsequent patches will upstream intrinsics support for BFloat16, followed by Matrix Multiplication and the remaining Virtualization features of the armv8.6-a architecture. Based on work by: - labrinea - MarkMurrayARM - Luke Cheeseman - Javed Asbar - Mikhail Maltsev - Luke Geeson Reviewers: SjoerdMeijer, craig.topper, rjmccall, jfb, LukeGeeson Reviewed By: SjoerdMeijer Subscribers: stuij, kristof.beyls, hiraditya, dexonsmith, danielkiss, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D76062
2020-03-26 16:17:29 +08:00
void AArch64TargetInfo::getTargetDefinesARMV86A(const LangOptions &Opts,
MacroBuilder &Builder) const {
// Also include the Armv8.5 defines
// FIXME: Armv8.6 makes the following extensions mandatory:
// - __ARM_FEATURE_BF16
// - __ARM_FEATURE_MATMUL_INT8
// Handle them here.
getTargetDefinesARMV85A(Opts, Builder);
}
[AArch64] Implement __jcvt intrinsic from Armv8.3-A The jcvt intrinsic defined in ACLE [1] is available when ARM_FEATURE_JCVT is defined. This change introduces the AArch64 intrinsic, wires it up to the instruction and a new clang builtin function. The __ARM_FEATURE_JCVT macro is now defined when an Armv8.3-A or higher target is used. I've implemented the target detection logic in Clang so that this feature is enabled for architectures from armv8.3-a onwards (so -march=armv8.4-a also enables this, for example). make check-all didn't show any new failures. [1] https://developer.arm.com/docs/101028/latest/data-processing-intrinsics Differential Revision: https://reviews.llvm.org/D64495 llvm-svn: 366197
2019-07-16 17:27:39 +08:00
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
void AArch64TargetInfo::getTargetDefines(const LangOptions &Opts,
MacroBuilder &Builder) const {
// Target identification.
Builder.defineMacro("__aarch64__");
[AArch64] Define __ELF__ for aarch64-none-elf and other similar triples. "aarch64-none-elf" is commonly used for AArch64 baremetal toolchains. Differential Revision: https://reviews.llvm.org/D53348 llvm-svn: 344710
2018-10-18 05:07:11 +08:00
// For bare-metal.
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
if (getTriple().getOS() == llvm::Triple::UnknownOS &&
[AArch64] Define __ELF__ for aarch64-none-elf and other similar triples. "aarch64-none-elf" is commonly used for AArch64 baremetal toolchains. Differential Revision: https://reviews.llvm.org/D53348 llvm-svn: 344710
2018-10-18 05:07:11 +08:00
getTriple().isOSBinFormatELF())
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
Builder.defineMacro("__ELF__");
// Target properties.
AArch64: add arm64_32 support to Clang.
2018-09-18 17:34:39 +08:00
if (!getTriple().isOSWindows() && getTriple().isArch64Bit()) {
[AArch64] Don't define __LP64__ when targeting Windows Windows/ARM64 is a LLP64 environment, so don't set this default define. Differential Revision: https://reviews.llvm.org/D36098 llvm-svn: 309619
2017-08-01 04:40:53 +08:00
Builder.defineMacro("_LP64");
Builder.defineMacro("__LP64__");
}
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
[AArch64] Predefine __AARCH64_CMODEL_*__ as GCC does Make Clang on aarch64 targets predefine `__AARCH64_CMODEL_SMALL__` or `__AARCH64_CMODEL_TINY__`, etc. These are the names that GCC uses for its predefines. Reviewed By: tamur, MaskRay Differential Revision: https://reviews.llvm.org/D75002
2020-02-22 13:25:57 +08:00
std::string CodeModel = getTargetOpts().CodeModel;
if (CodeModel == "default")
CodeModel = "small";
for (char &c : CodeModel)
c = toupper(c);
Builder.defineMacro("__AARCH64_CMODEL_" + CodeModel + "__");
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
// ACLE predefines. Many can only have one possible value on v8 AArch64.
Builder.defineMacro("__ARM_ACLE", "200");
Builder.defineMacro("__ARM_ARCH", "8");
Builder.defineMacro("__ARM_ARCH_PROFILE", "'A'");
Builder.defineMacro("__ARM_64BIT_STATE", "1");
Builder.defineMacro("__ARM_PCS_AAPCS64", "1");
Builder.defineMacro("__ARM_ARCH_ISA_A64", "1");
Builder.defineMacro("__ARM_FEATURE_CLZ", "1");
Builder.defineMacro("__ARM_FEATURE_FMA", "1");
Builder.defineMacro("__ARM_FEATURE_LDREX", "0xF");
Builder.defineMacro("__ARM_FEATURE_IDIV", "1"); // As specified in ACLE
Builder.defineMacro("__ARM_FEATURE_DIV"); // For backwards compatibility
Builder.defineMacro("__ARM_FEATURE_NUMERIC_MAXMIN", "1");
Builder.defineMacro("__ARM_FEATURE_DIRECTED_ROUNDING", "1");
Builder.defineMacro("__ARM_ALIGN_MAX_STACK_PWR", "4");
// 0xe implies support for half, single and double precision operations.
Builder.defineMacro("__ARM_FP", "0xE");
// PCS specifies this for SysV variants, which is all we support. Other ABIs
// may choose __ARM_FP16_FORMAT_ALTERNATIVE.
Builder.defineMacro("__ARM_FP16_FORMAT_IEEE", "1");
Builder.defineMacro("__ARM_FP16_ARGS", "1");
if (Opts.UnsafeFPMath)
Builder.defineMacro("__ARM_FP_FAST", "1");
Driver: hoist the `wchar_t` handling to the driver Move the logic for determining the `wchar_t` type information into the driver. Rather than passing the single bit of information of `-fshort-wchar` indicate to the frontend the desired type of `wchar_t` through a new `-cc1` option of `-fwchar-type` and indicate the signedness through `-f{,no-}signed-wchar`. This replicates the current logic which was spread throughout Basic into the `RenderCharacterOptions`. Most of the changes to the tests are to ensure that the frontend uses the correct type. Add a new test set under `test/Driver/wchar_t.c` to ensure that we calculate the proper types for the various cases. llvm-svn: 315126
2017-10-07 07:09:55 +08:00
Builder.defineMacro("__ARM_SIZEOF_WCHAR_T",
Avoid int to string conversion in Twine or raw_ostream contexts. Some output changes from uppercase hex to lowercase hex, no other functionality change intended. llvm-svn: 321526
2017-12-29 00:58:54 +08:00
Twine(Opts.WCharSize ? Opts.WCharSize : 4));
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
Builder.defineMacro("__ARM_SIZEOF_MINIMAL_ENUM", Opts.ShortEnums ? "1" : "4");
if (FPU & NeonMode) {
Builder.defineMacro("__ARM_NEON", "1");
// 64-bit NEON supports half, single and double precision operations.
Builder.defineMacro("__ARM_NEON_FP", "0xE");
}
[AArch64][SVE] Enable __ARM_FEATURE_SVE macros. This patch enables the following macros when their corresponding target attributes are set: __ARM_FEATURE_SVE (+sve) __ARM_FEATURE_SVE2 (+sve2) __ARM_FEATURE_SVE2_AES (+sve2-aes) __ARM_FEATURE_SVE2_BITPERM (+sve2-bitperm) __ARM_FEATURE_SVE2_SHA3 (+sve2-sha3) __ARM_FEATURE_SVE2_SM4 (+sve2-sm4) This implies that the base SVE and SVE2 ACLE (00bet2) are now feature complete, meaning that all intrinsics are implemented in LLVM and Clang. Disclaimer: To implement the ACLE we have had to fix up many parts of LLVM to make it support scalable vectors. We have also used many target-specific intrinsics to reduce reliance on parts of LLVM where we know scalable vectors may not yet be handled properly (e.g. some transformation might drop the 'scalable' flag on a vector type). While we've done a best effort with the limited testing that is available to us, we're still working to improve the stability of the implementation. Additionally, Clang may print warnings that code may have miscompiled. We find this often to be a false alarm where the wrong interfaces have been used in LLVM and where resulting code is not actually incorrect. However, this warrants a bug report and investigation. If you find any bugs or issues, please raise them on bugs.llvm.org and let us know! Reviewers: rengolin, efriedma, david-arm, SjoerdMeijer Reviewed By: SjoerdMeijer Differential Revision: https://reviews.llvm.org/D81725
2020-06-24 23:52:41 +08:00
if (FPU & SveMode)
Builder.defineMacro("__ARM_FEATURE_SVE", "1");
if (HasSVE2)
Builder.defineMacro("__ARM_FEATURE_SVE2", "1");
if (HasSVE2 && HasSVE2AES)
Builder.defineMacro("__ARM_FEATURE_SVE2_AES", "1");
if (HasSVE2 && HasSVE2BitPerm)
Builder.defineMacro("__ARM_FEATURE_SVE2_BITPERM", "1");
if (HasSVE2 && HasSVE2SHA3)
Builder.defineMacro("__ARM_FEATURE_SVE2_SHA3", "1");
if (HasSVE2 && HasSVE2SM4)
Builder.defineMacro("__ARM_FEATURE_SVE2_SM4", "1");
[AArch64] Consistent types and naming for AArch64 target features (NFC) Differential Revision: https://reviews.llvm.org/D64415 Committed as obvious. llvm-svn: 366315
2019-07-17 19:24:37 +08:00
if (HasCRC)
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
Builder.defineMacro("__ARM_FEATURE_CRC32", "1");
[AArch64] Consistent types and naming for AArch64 target features (NFC) Differential Revision: https://reviews.llvm.org/D64415 Committed as obvious. llvm-svn: 366315
2019-07-17 19:24:37 +08:00
if (HasCrypto)
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
Builder.defineMacro("__ARM_FEATURE_CRYPTO", "1");
[AArch64] Consistent types and naming for AArch64 target features (NFC) Differential Revision: https://reviews.llvm.org/D64415 Committed as obvious. llvm-svn: 366315
2019-07-17 19:24:37 +08:00
if (HasUnaligned)
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
Builder.defineMacro("__ARM_FEATURE_UNALIGNED", "1");
[AARch64] Add ARMv8.2-A FP16 vector intrinsics Putting back the code that was reverted few weeks ago. Differential Revision: https://reviews.llvm.org/D34161 llvm-svn: 321294
2017-12-22 03:20:01 +08:00
if ((FPU & NeonMode) && HasFullFP16)
Builder.defineMacro("__ARM_FEATURE_FP16_VECTOR_ARITHMETIC", "1");
[AArch64] Add ARMv8.2-A FP16 scalar intrinsics https://reviews.llvm.org/D41792 llvm-svn: 323006
2018-01-20 07:11:18 +08:00
if (HasFullFP16)
Builder.defineMacro("__ARM_FEATURE_FP16_SCALAR_ARITHMETIC", "1");
[AARch64] Add ARMv8.2-A FP16 vector intrinsics Putting back the code that was reverted few weeks ago. Differential Revision: https://reviews.llvm.org/D34161 llvm-svn: 321294
2017-12-22 03:20:01 +08:00
[AAch64] Add the __ARM_FEATURE_DOTPROD macro definition This matches what GCC does. https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aarch64/aarch64-c.c Differential Revision: https://reviews.llvm.org/D45544 llvm-svn: 330229
2018-04-18 06:38:40 +08:00
if (HasDotProd)
Builder.defineMacro("__ARM_FEATURE_DOTPROD", "1");
[AArch64] Add support for MTE intrinsics This provides intrinsics support for Memory Tagging Extension (MTE), which was introduced with the Armv8.5-a architecture. These intrinsics are available when __ARM_FEATURE_MEMORY_TAGGING is defined. Each intrinsic is described in detail in the ACLE Q1 2019 documentation: https://developer.arm.com/docs/101028/latest Reviewed By: Tim Nortover, David Spickett Differential Revision: https://reviews.llvm.org/D60485 llvm-svn: 359348
2019-04-27 05:08:11 +08:00
if (HasMTE)
Builder.defineMacro("__ARM_FEATURE_MEMORY_TAGGING", "1");
[AArch64] Add support for Transactional Memory Extension (TME) Re-commit r366322 after some fixes TME is a future architecture technology, documented in https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools https://developer.arm.com/docs/ddi0601/a More about the future architectures: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/new-technologies-for-the-arm-a-profile-architecture This patch adds support for the TME instructions TSTART, TTEST, TCOMMIT, and TCANCEL and the target feature/arch extension "tme". It also implements TME builtin functions, defined in ACLE Q2 2019 (https://developer.arm.com/docs/101028/latest) Differential Revision: https://reviews.llvm.org/D64416 Patch by Javed Absar and Momchil Velikov llvm-svn: 367428
2019-07-31 20:52:17 +08:00
if (HasTME)
Builder.defineMacro("__ARM_FEATURE_TME", "1");
[AArch64] Armv8.6-a Matrix Mult Assembly + Intrinsics This patch upstreams support for the Armv8.6-a Matrix Multiplication Extension. A summary of the features can be found here: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a This patch includes: - Assembly support for AArch64 only (no SVE or Neon) - Intrinsics Support for AArch64 Armv8.6a Matrix Multiplication Instructions (No bfloat16 matrix multiplication) No IR types or C Types are needed for this extension. This is part of a patch series, starting with BFloat16 support and the other components in the armv8.6a extension (in previous patches linked in phabricator) Based on work by: - Luke Geeson - Oliver Stannard - Luke Cheeseman Reviewers: ostannard, t.p.northover, rengolin, kmclaughlin Reviewed By: kmclaughlin Subscribers: kmclaughlin, kristof.beyls, hiraditya, danielkiss, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77871
2020-04-10 00:21:19 +08:00
if (HasMatMul)
Builder.defineMacro("__ARM_FEATURE_MATMUL_INT8", "1");
[AArch64] Define __ARM_FEATURE_{CRC32,ATOMICS} This patch implements the definition of __ARM_FEATURE_ATOMICS and fixes the missing definition of __ARM_FEATURE_CRC32 for Armv8.1-A. Differential Revision: https://reviews.llvm.org/D91438
2020-11-13 21:56:43 +08:00
if (HasLSE)
Builder.defineMacro("__ARM_FEATURE_ATOMICS", "1");
[clang][BFloat] add NEON emitter for bfloat Summary: This patch adds the bfloat16_t struct typedefs (e.g. bfloat16x8x2_t) to arm_neon.h This patch is part of a series implementing the Bfloat16 extension of the Armv8.6-a architecture, as detailed here: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a The bfloat type, and its properties are specified in the Arm Architecture Reference Manual: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile The following people contributed to this patch: - Luke Cheeseman - Simon Tatham - Ties Stuij Reviewers: t.p.northover, fpetrogalli, sdesmalen, az, LukeGeeson Reviewed By: fpetrogalli Subscribers: SjoerdMeijer, LukeGeeson, pbarrio, mgorny, kristof.beyls, ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D79708
2020-06-05 20:06:01 +08:00
if (HasBFloat16) {
Builder.defineMacro("__ARM_FEATURE_BF16", "1");
Builder.defineMacro("__ARM_FEATURE_BF16_VECTOR_ARITHMETIC", "1");
Builder.defineMacro("__ARM_BF16_FORMAT_ALTERNATIVE", "1");
[sve][acle] Enable feature macros for SVE ACLE extensions. Summary: The following feature macros have been added: __ARM_FEATURE_SVE_BF16 __ARM_FEATURE_SVE_MATMUL_INT8 __ARM_FEATURE_SVE_MATMUL_FP32 __ARM_FEATURE_SVE_MATMUL_FP64 The driver has been updated to enable them accordingly to the value of the target feature passed at command line. The SVE ACLE tests using the macros have been modified to work with the target feature instead of passing the macro at command line. Reviewers: sdesmalen, efriedma, c-rhodes, kmclaughlin, SjoerdMeijer, rengolin Subscribers: tschuett, kristof.beyls, rkruppe, psnobl, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D82623
2020-06-26 05:49:00 +08:00
Builder.defineMacro("__ARM_FEATURE_BF16_SCALAR_ARITHMETIC", "1");
[clang][BFloat] add NEON emitter for bfloat Summary: This patch adds the bfloat16_t struct typedefs (e.g. bfloat16x8x2_t) to arm_neon.h This patch is part of a series implementing the Bfloat16 extension of the Armv8.6-a architecture, as detailed here: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a The bfloat type, and its properties are specified in the Arm Architecture Reference Manual: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile The following people contributed to this patch: - Luke Cheeseman - Simon Tatham - Ties Stuij Reviewers: t.p.northover, fpetrogalli, sdesmalen, az, LukeGeeson Reviewed By: fpetrogalli Subscribers: SjoerdMeijer, LukeGeeson, pbarrio, mgorny, kristof.beyls, ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D79708
2020-06-05 20:06:01 +08:00
}
[sve][acle] Enable feature macros for SVE ACLE extensions. Summary: The following feature macros have been added: __ARM_FEATURE_SVE_BF16 __ARM_FEATURE_SVE_MATMUL_INT8 __ARM_FEATURE_SVE_MATMUL_FP32 __ARM_FEATURE_SVE_MATMUL_FP64 The driver has been updated to enable them accordingly to the value of the target feature passed at command line. The SVE ACLE tests using the macros have been modified to work with the target feature instead of passing the macro at command line. Reviewers: sdesmalen, efriedma, c-rhodes, kmclaughlin, SjoerdMeijer, rengolin Subscribers: tschuett, kristof.beyls, rkruppe, psnobl, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D82623
2020-06-26 05:49:00 +08:00
if ((FPU & SveMode) && HasBFloat16) {
Builder.defineMacro("__ARM_FEATURE_SVE_BF16", "1");
}
if ((FPU & SveMode) && HasMatmulFP64)
Builder.defineMacro("__ARM_FEATURE_SVE_MATMUL_FP64", "1");
if ((FPU & SveMode) && HasMatmulFP32)
Builder.defineMacro("__ARM_FEATURE_SVE_MATMUL_FP32", "1");
if ((FPU & SveMode) && HasMatMul)
Builder.defineMacro("__ARM_FEATURE_SVE_MATMUL_INT8", "1");
[AArch64] Implement FP16FML intrinsics Generate the FP16FML intrinsics into arm_neon.h (AArch64 only for now). Add two new type modifiers to NeonEmitter to handle the new prototypes. Define __ARM_FEATURE_FP16FML when +fp16fml is enabled and guard the intrinsics with the macro in arm_neon.h. Based on a patch by Gao Yiling. Differential Revision: https://reviews.llvm.org/D53633 llvm-svn: 345344
2018-10-26 07:47:00 +08:00
if ((FPU & NeonMode) && HasFP16FML)
Builder.defineMacro("__ARM_FEATURE_FP16FML", "1");
[clang][AARCH64] Add __ARM_FEATURE_{PAC, BTI}_DEFAULT defines Summary: As defined by Arm C Language Extensions (ACLE) these macro defines should be set to specific values depending on -mbranch-protection. Reviewers: chill Reviewed By: chill Subscribers: danielkiss, cfe-commits, kristof.beyls Tags: #clang Differential Revision: https://reviews.llvm.org/D77134
2020-04-02 18:10:41 +08:00
if (Opts.hasSignReturnAddress()) {
// Bitmask:
// 0: Protection using the A key
// 1: Protection using the B key
// 2: Protection including leaf functions
unsigned Value = 0;
if (Opts.isSignReturnAddressWithAKey())
Value |= (1 << 0);
else
Value |= (1 << 1);
if (Opts.isSignReturnAddressScopeAll())
Value |= (1 << 2);
Builder.defineMacro("__ARM_FEATURE_PAC_DEFAULT", std::to_string(Value));
}
if (Opts.BranchTargetEnforcement)
Builder.defineMacro("__ARM_FEATURE_BTI_DEFAULT", "1");
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
switch (ArchKind) {
default:
break;
Update to use enum classes for various ARM *Kind enums Summary: This updates the relevant Clang parts for the LLVM change D35882. Reviewers: rengolin, chandlerc, javed.absar, rovka Reviewed By: rovka Subscribers: aemerson, cfe-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D35884 llvm-svn: 309289
2017-07-28 00:28:39 +08:00
case llvm::AArch64::ArchKind::ARMV8_1A:
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
getTargetDefinesARMV81A(Opts, Builder);
break;
Update to use enum classes for various ARM *Kind enums Summary: This updates the relevant Clang parts for the LLVM change D35882. Reviewers: rengolin, chandlerc, javed.absar, rovka Reviewed By: rovka Subscribers: aemerson, cfe-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D35884 llvm-svn: 309289
2017-07-28 00:28:39 +08:00
case llvm::AArch64::ArchKind::ARMV8_2A:
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
getTargetDefinesARMV82A(Opts, Builder);
break;
[AArch64] Implement __jcvt intrinsic from Armv8.3-A The jcvt intrinsic defined in ACLE [1] is available when ARM_FEATURE_JCVT is defined. This change introduces the AArch64 intrinsic, wires it up to the instruction and a new clang builtin function. The __ARM_FEATURE_JCVT macro is now defined when an Armv8.3-A or higher target is used. I've implemented the target detection logic in Clang so that this feature is enabled for architectures from armv8.3-a onwards (so -march=armv8.4-a also enables this, for example). make check-all didn't show any new failures. [1] https://developer.arm.com/docs/101028/latest/data-processing-intrinsics Differential Revision: https://reviews.llvm.org/D64495 llvm-svn: 366197
2019-07-16 17:27:39 +08:00
case llvm::AArch64::ArchKind::ARMV8_3A:
getTargetDefinesARMV83A(Opts, Builder);
break;
case llvm::AArch64::ArchKind::ARMV8_4A:
getTargetDefinesARMV84A(Opts, Builder);
break;
case llvm::AArch64::ArchKind::ARMV8_5A:
getTargetDefinesARMV85A(Opts, Builder);
break;
[PATCH] [ARM] ARMv8.6-a command-line + BFloat16 Asm Support Summary: This patch introduces command-line support for the Armv8.6-a architecture and assembly support for BFloat16. Details can be found https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a in addition to the GCC patch for the 8..6-a CLI: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-11/msg02647.html In detail this patch - march options for armv8.6-a - BFloat16 assembly This is part of a patch series, starting with command-line and Bfloat16 assembly support. The subsequent patches will upstream intrinsics support for BFloat16, followed by Matrix Multiplication and the remaining Virtualization features of the armv8.6-a architecture. Based on work by: - labrinea - MarkMurrayARM - Luke Cheeseman - Javed Asbar - Mikhail Maltsev - Luke Geeson Reviewers: SjoerdMeijer, craig.topper, rjmccall, jfb, LukeGeeson Reviewed By: SjoerdMeijer Subscribers: stuij, kristof.beyls, hiraditya, dexonsmith, danielkiss, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D76062
2020-03-26 16:17:29 +08:00
case llvm::AArch64::ArchKind::ARMV8_6A:
getTargetDefinesARMV86A(Opts, Builder);
break;
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
}
// All of the __sync_(bool|val)_compare_and_swap_(1|2|4|8) builtins work.
Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1");
Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2");
Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4");
Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8");
[Sema][AArch64] Add parsing support for arm_sve_vector_bits attribute Summary: This patch implements parsing support for the 'arm_sve_vector_bits' type attribute, defined by the Arm C Language Extensions (ACLE, version 00bet5, section 3.7.3) for SVE [1]. The purpose of this attribute is to define fixed-length (VLST) versions of existing sizeless types (VLAT). For example: #if __ARM_FEATURE_SVE_BITS==512 typedef svint32_t fixed_svint32_t __attribute__((arm_sve_vector_bits(512))); #endif Creates a type 'fixed_svint32_t' that is a fixed-length version of 'svint32_t' that is normal-sized (rather than sizeless) and contains exactly 512 bits. Unlike 'svint32_t', this type can be used in places such as structs and arrays where sizeless types can't. Implemented in this patch is the following: * Defined and tested attribute taking single argument. * Checks the argument is an integer constant expression. * Attribute can only be attached to a single SVE vector or predicate type, excluding tuple types such as svint32x4_t. * Added the `-msve-vector-bits=<bits>` flag. When specified the `__ARM_FEATURE_SVE_BITS__EXPERIMENTAL` macro is defined. * Added a language option to store the vector size specified by the `-msve-vector-bits=<bits>` flag. This is used to validate `N == __ARM_FEATURE_SVE_BITS`, where N is the number of bits passed to the attribute and `__ARM_FEATURE_SVE_BITS` is the feature macro defined under the same flag. The `__ARM_FEATURE_SVE_BITS` macro will be made non-experimental in the final patch of the series. [1] https://developer.arm.com/documentation/100987/latest This is patch 1/4 of a patch series. Reviewers: sdesmalen, rsandifo-arm, efriedma, ctetreau, cameron.mcinally, rengolin, aaron.ballman Reviewed By: sdesmalen, aaron.ballman Differential Revision: https://reviews.llvm.org/D83550
2020-05-29 17:17:37 +08:00
[clang][SVE] Activate macro `__ARM_FEATURE_SVE_VECTOR_OPERATORS`. The macro is emitted when wargeting SVE code generation with the additional command line option `-msve-vector-bits=<N>`. The behavior implied by the macro is described in sections "3.7.3.3. Behavior specific to SVE vectors" of the SVE ACLE (Version 00bet6) that can be found at https://developer.arm.com/documentation/100987/latest Reviewed By: rengolin, rsandifo-arm Differential Revision: https://reviews.llvm.org/D90956
2020-11-25 17:37:00 +08:00
if (Opts.ArmSveVectorBits) {
[clang][aarch64] Drop experimental from __ARM_FEATURE_SVE_BITS macro The __ARM_FEATURE_SVE_BITS feature macro is specified in the Arm C Language Extensions (ACLE) for SVE [1] (version 00bet5). From the spec, where __ARM_FEATURE_SVE_BITS==N: When N is nonzero, indicates that the implementation is generating code for an N-bit SVE target and that the arm_sve_vector_bits(N) attribute is available. This was defined in D83550 as __ARM_FEATURE_SVE_BITS_EXPERIMENTAL and enabled under the -msve-vector-bits flag to simplify initial tests. This patch drops _EXPERIMENTAL now there is support for the feature. [1] https://developer.arm.com/documentation/100987/latest Reviewed By: david-arm Differential Revision: https://reviews.llvm.org/D86720
2020-09-03 17:19:41 +08:00
Builder.defineMacro("__ARM_FEATURE_SVE_BITS", Twine(Opts.ArmSveVectorBits));
[clang][SVE] Activate macro `__ARM_FEATURE_SVE_VECTOR_OPERATORS`. The macro is emitted when wargeting SVE code generation with the additional command line option `-msve-vector-bits=<N>`. The behavior implied by the macro is described in sections "3.7.3.3. Behavior specific to SVE vectors" of the SVE ACLE (Version 00bet6) that can be found at https://developer.arm.com/documentation/100987/latest Reviewed By: rengolin, rsandifo-arm Differential Revision: https://reviews.llvm.org/D90956
2020-11-25 17:37:00 +08:00
Builder.defineMacro("__ARM_FEATURE_SVE_VECTOR_OPERATORS");
}
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
}
ArrayRef<Builtin::Info> AArch64TargetInfo::getTargetBuiltins() const {
return llvm::makeArrayRef(BuiltinInfo, clang::AArch64::LastTSBuiltin -
Builtin::FirstTSBuiltin);
}
bool AArch64TargetInfo::hasFeature(StringRef Feature) const {
return Feature == "aarch64" || Feature == "arm64" || Feature == "arm" ||
(Feature == "neon" && (FPU & NeonMode)) ||
[AArch64][SVE] Enable __ARM_FEATURE_SVE macros. This patch enables the following macros when their corresponding target attributes are set: __ARM_FEATURE_SVE (+sve) __ARM_FEATURE_SVE2 (+sve2) __ARM_FEATURE_SVE2_AES (+sve2-aes) __ARM_FEATURE_SVE2_BITPERM (+sve2-bitperm) __ARM_FEATURE_SVE2_SHA3 (+sve2-sha3) __ARM_FEATURE_SVE2_SM4 (+sve2-sm4) This implies that the base SVE and SVE2 ACLE (00bet2) are now feature complete, meaning that all intrinsics are implemented in LLVM and Clang. Disclaimer: To implement the ACLE we have had to fix up many parts of LLVM to make it support scalable vectors. We have also used many target-specific intrinsics to reduce reliance on parts of LLVM where we know scalable vectors may not yet be handled properly (e.g. some transformation might drop the 'scalable' flag on a vector type). While we've done a best effort with the limited testing that is available to us, we're still working to improve the stability of the implementation. Additionally, Clang may print warnings that code may have miscompiled. We find this often to be a false alarm where the wrong interfaces have been used in LLVM and where resulting code is not actually incorrect. However, this warrants a bug report and investigation. If you find any bugs or issues, please raise them on bugs.llvm.org and let us know! Reviewers: rengolin, efriedma, david-arm, SjoerdMeijer Reviewed By: SjoerdMeijer Differential Revision: https://reviews.llvm.org/D81725
2020-06-24 23:52:41 +08:00
((Feature == "sve" || Feature == "sve2" || Feature == "sve2-bitperm" ||
Feature == "sve2-aes" || Feature == "sve2-sha3" ||
[sve][acle] Enable feature macros for SVE ACLE extensions. Summary: The following feature macros have been added: __ARM_FEATURE_SVE_BF16 __ARM_FEATURE_SVE_MATMUL_INT8 __ARM_FEATURE_SVE_MATMUL_FP32 __ARM_FEATURE_SVE_MATMUL_FP64 The driver has been updated to enable them accordingly to the value of the target feature passed at command line. The SVE ACLE tests using the macros have been modified to work with the target feature instead of passing the macro at command line. Reviewers: sdesmalen, efriedma, c-rhodes, kmclaughlin, SjoerdMeijer, rengolin Subscribers: tschuett, kristof.beyls, rkruppe, psnobl, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D82623
2020-06-26 05:49:00 +08:00
Feature == "sve2-sm4" || Feature == "f64mm" || Feature == "f32mm" ||
Feature == "i8mm" || Feature == "bf16") &&
[AArch64][SVE] Enable __ARM_FEATURE_SVE macros. This patch enables the following macros when their corresponding target attributes are set: __ARM_FEATURE_SVE (+sve) __ARM_FEATURE_SVE2 (+sve2) __ARM_FEATURE_SVE2_AES (+sve2-aes) __ARM_FEATURE_SVE2_BITPERM (+sve2-bitperm) __ARM_FEATURE_SVE2_SHA3 (+sve2-sha3) __ARM_FEATURE_SVE2_SM4 (+sve2-sm4) This implies that the base SVE and SVE2 ACLE (00bet2) are now feature complete, meaning that all intrinsics are implemented in LLVM and Clang. Disclaimer: To implement the ACLE we have had to fix up many parts of LLVM to make it support scalable vectors. We have also used many target-specific intrinsics to reduce reliance on parts of LLVM where we know scalable vectors may not yet be handled properly (e.g. some transformation might drop the 'scalable' flag on a vector type). While we've done a best effort with the limited testing that is available to us, we're still working to improve the stability of the implementation. Additionally, Clang may print warnings that code may have miscompiled. We find this often to be a false alarm where the wrong interfaces have been used in LLVM and where resulting code is not actually incorrect. However, this warrants a bug report and investigation. If you find any bugs or issues, please raise them on bugs.llvm.org and let us know! Reviewers: rengolin, efriedma, david-arm, SjoerdMeijer Reviewed By: SjoerdMeijer Differential Revision: https://reviews.llvm.org/D81725
2020-06-24 23:52:41 +08:00
(FPU & SveMode));
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
}
bool AArch64TargetInfo::handleTargetFeatures(std::vector<std::string> &Features,
DiagnosticsEngine &Diags) {
FPU = FPUMode;
[AArch64] Consistent types and naming for AArch64 target features (NFC) Differential Revision: https://reviews.llvm.org/D64415 Committed as obvious. llvm-svn: 366315
2019-07-17 19:24:37 +08:00
HasCRC = false;
HasCrypto = false;
HasUnaligned = true;
HasFullFP16 = false;
HasDotProd = false;
HasFP16FML = false;
HasMTE = false;
[AArch64] Add support for Transactional Memory Extension (TME) Re-commit r366322 after some fixes TME is a future architecture technology, documented in https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools https://developer.arm.com/docs/ddi0601/a More about the future architectures: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/new-technologies-for-the-arm-a-profile-architecture This patch adds support for the TME instructions TSTART, TTEST, TCOMMIT, and TCANCEL and the target feature/arch extension "tme". It also implements TME builtin functions, defined in ACLE Q2 2019 (https://developer.arm.com/docs/101028/latest) Differential Revision: https://reviews.llvm.org/D64416 Patch by Javed Absar and Momchil Velikov llvm-svn: 367428
2019-07-31 20:52:17 +08:00
HasTME = false;
[AArch64] Armv8.6-a Matrix Mult Assembly + Intrinsics This patch upstreams support for the Armv8.6-a Matrix Multiplication Extension. A summary of the features can be found here: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a This patch includes: - Assembly support for AArch64 only (no SVE or Neon) - Intrinsics Support for AArch64 Armv8.6a Matrix Multiplication Instructions (No bfloat16 matrix multiplication) No IR types or C Types are needed for this extension. This is part of a patch series, starting with BFloat16 support and the other components in the armv8.6a extension (in previous patches linked in phabricator) Based on work by: - Luke Geeson - Oliver Stannard - Luke Cheeseman Reviewers: ostannard, t.p.northover, rengolin, kmclaughlin Reviewed By: kmclaughlin Subscribers: kmclaughlin, kristof.beyls, hiraditya, danielkiss, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77871
2020-04-10 00:21:19 +08:00
HasMatMul = false;
[ARM] Add __bf16 as new Bfloat16 C Type Summary: This patch upstreams support for a new storage only bfloat16 C type. This type is used to implement primitive support for bfloat16 data, in line with the Bfloat16 extension of the Armv8.6-a architecture, as detailed here: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a The bfloat type, and its properties are specified in the Arm Architecture Reference Manual: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile In detail this patch: - introduces an opaque, storage-only C-type __bf16, which introduces a new bfloat IR type. This is part of a patch series, starting with command-line and Bfloat16 assembly support. The subsequent patches will upstream intrinsics support for BFloat16, followed by Matrix Multiplication and the remaining Virtualization features of the armv8.6-a architecture. The following people contributed to this patch: - Luke Cheeseman - Momchil Velikov - Alexandros Lamprineas - Luke Geeson - Simon Tatham - Ties Stuij Reviewers: SjoerdMeijer, rjmccall, rsmith, liutianle, RKSimon, craig.topper, jfb, LukeGeeson, fpetrogalli Reviewed By: SjoerdMeijer Subscribers: labrinea, majnemer, asmith, dexonsmith, kristof.beyls, arphaman, danielkiss, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D76077
2020-06-05 07:20:02 +08:00
HasBFloat16 = false;
[AArch64][SVE] Enable __ARM_FEATURE_SVE macros. This patch enables the following macros when their corresponding target attributes are set: __ARM_FEATURE_SVE (+sve) __ARM_FEATURE_SVE2 (+sve2) __ARM_FEATURE_SVE2_AES (+sve2-aes) __ARM_FEATURE_SVE2_BITPERM (+sve2-bitperm) __ARM_FEATURE_SVE2_SHA3 (+sve2-sha3) __ARM_FEATURE_SVE2_SM4 (+sve2-sm4) This implies that the base SVE and SVE2 ACLE (00bet2) are now feature complete, meaning that all intrinsics are implemented in LLVM and Clang. Disclaimer: To implement the ACLE we have had to fix up many parts of LLVM to make it support scalable vectors. We have also used many target-specific intrinsics to reduce reliance on parts of LLVM where we know scalable vectors may not yet be handled properly (e.g. some transformation might drop the 'scalable' flag on a vector type). While we've done a best effort with the limited testing that is available to us, we're still working to improve the stability of the implementation. Additionally, Clang may print warnings that code may have miscompiled. We find this often to be a false alarm where the wrong interfaces have been used in LLVM and where resulting code is not actually incorrect. However, this warrants a bug report and investigation. If you find any bugs or issues, please raise them on bugs.llvm.org and let us know! Reviewers: rengolin, efriedma, david-arm, SjoerdMeijer Reviewed By: SjoerdMeijer Differential Revision: https://reviews.llvm.org/D81725
2020-06-24 23:52:41 +08:00
HasSVE2 = false;
HasSVE2AES = false;
HasSVE2SHA3 = false;
HasSVE2SM4 = false;
HasSVE2BitPerm = false;
[sve][acle] Enable feature macros for SVE ACLE extensions. Summary: The following feature macros have been added: __ARM_FEATURE_SVE_BF16 __ARM_FEATURE_SVE_MATMUL_INT8 __ARM_FEATURE_SVE_MATMUL_FP32 __ARM_FEATURE_SVE_MATMUL_FP64 The driver has been updated to enable them accordingly to the value of the target feature passed at command line. The SVE ACLE tests using the macros have been modified to work with the target feature instead of passing the macro at command line. Reviewers: sdesmalen, efriedma, c-rhodes, kmclaughlin, SjoerdMeijer, rengolin Subscribers: tschuett, kristof.beyls, rkruppe, psnobl, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D82623
2020-06-26 05:49:00 +08:00
HasMatmulFP64 = false;
HasMatmulFP32 = false;
[AArch64] Define __ARM_FEATURE_{CRC32,ATOMICS} This patch implements the definition of __ARM_FEATURE_ATOMICS and fixes the missing definition of __ARM_FEATURE_CRC32 for Armv8.1-A. Differential Revision: https://reviews.llvm.org/D91438
2020-11-13 21:56:43 +08:00
HasLSE = false;
[AArch64][SVE] Enable __ARM_FEATURE_SVE macros. This patch enables the following macros when their corresponding target attributes are set: __ARM_FEATURE_SVE (+sve) __ARM_FEATURE_SVE2 (+sve2) __ARM_FEATURE_SVE2_AES (+sve2-aes) __ARM_FEATURE_SVE2_BITPERM (+sve2-bitperm) __ARM_FEATURE_SVE2_SHA3 (+sve2-sha3) __ARM_FEATURE_SVE2_SM4 (+sve2-sm4) This implies that the base SVE and SVE2 ACLE (00bet2) are now feature complete, meaning that all intrinsics are implemented in LLVM and Clang. Disclaimer: To implement the ACLE we have had to fix up many parts of LLVM to make it support scalable vectors. We have also used many target-specific intrinsics to reduce reliance on parts of LLVM where we know scalable vectors may not yet be handled properly (e.g. some transformation might drop the 'scalable' flag on a vector type). While we've done a best effort with the limited testing that is available to us, we're still working to improve the stability of the implementation. Additionally, Clang may print warnings that code may have miscompiled. We find this often to be a false alarm where the wrong interfaces have been used in LLVM and where resulting code is not actually incorrect. However, this warrants a bug report and investigation. If you find any bugs or issues, please raise them on bugs.llvm.org and let us know! Reviewers: rengolin, efriedma, david-arm, SjoerdMeijer Reviewed By: SjoerdMeijer Differential Revision: https://reviews.llvm.org/D81725
2020-06-24 23:52:41 +08:00
Update to use enum classes for various ARM *Kind enums Summary: This updates the relevant Clang parts for the LLVM change D35882. Reviewers: rengolin, chandlerc, javed.absar, rovka Reviewed By: rovka Subscribers: aemerson, cfe-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D35884 llvm-svn: 309289
2017-07-28 00:28:39 +08:00
ArchKind = llvm::AArch64::ArchKind::ARMV8A;
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
for (const auto &Feature : Features) {
if (Feature == "+neon")
FPU |= NeonMode;
[AArch64][SVE] Enable __ARM_FEATURE_SVE macros. This patch enables the following macros when their corresponding target attributes are set: __ARM_FEATURE_SVE (+sve) __ARM_FEATURE_SVE2 (+sve2) __ARM_FEATURE_SVE2_AES (+sve2-aes) __ARM_FEATURE_SVE2_BITPERM (+sve2-bitperm) __ARM_FEATURE_SVE2_SHA3 (+sve2-sha3) __ARM_FEATURE_SVE2_SM4 (+sve2-sm4) This implies that the base SVE and SVE2 ACLE (00bet2) are now feature complete, meaning that all intrinsics are implemented in LLVM and Clang. Disclaimer: To implement the ACLE we have had to fix up many parts of LLVM to make it support scalable vectors. We have also used many target-specific intrinsics to reduce reliance on parts of LLVM where we know scalable vectors may not yet be handled properly (e.g. some transformation might drop the 'scalable' flag on a vector type). While we've done a best effort with the limited testing that is available to us, we're still working to improve the stability of the implementation. Additionally, Clang may print warnings that code may have miscompiled. We find this often to be a false alarm where the wrong interfaces have been used in LLVM and where resulting code is not actually incorrect. However, this warrants a bug report and investigation. If you find any bugs or issues, please raise them on bugs.llvm.org and let us know! Reviewers: rengolin, efriedma, david-arm, SjoerdMeijer Reviewed By: SjoerdMeijer Differential Revision: https://reviews.llvm.org/D81725
2020-06-24 23:52:41 +08:00
if (Feature == "+sve") {
FPU |= SveMode;
HasFullFP16 = 1;
}
if (Feature == "+sve2") {
FPU |= SveMode;
HasFullFP16 = 1;
HasSVE2 = 1;
}
if (Feature == "+sve2-aes") {
FPU |= SveMode;
HasFullFP16 = 1;
HasSVE2 = 1;
HasSVE2AES = 1;
}
if (Feature == "+sve2-sha3") {
FPU |= SveMode;
HasFullFP16 = 1;
HasSVE2 = 1;
HasSVE2SHA3 = 1;
}
if (Feature == "+sve2-sm4") {
FPU |= SveMode;
HasFullFP16 = 1;
HasSVE2 = 1;
HasSVE2SM4 = 1;
}
if (Feature == "+sve2-bitperm") {
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
FPU |= SveMode;
[AArch64][SVE] Enable __ARM_FEATURE_SVE macros. This patch enables the following macros when their corresponding target attributes are set: __ARM_FEATURE_SVE (+sve) __ARM_FEATURE_SVE2 (+sve2) __ARM_FEATURE_SVE2_AES (+sve2-aes) __ARM_FEATURE_SVE2_BITPERM (+sve2-bitperm) __ARM_FEATURE_SVE2_SHA3 (+sve2-sha3) __ARM_FEATURE_SVE2_SM4 (+sve2-sm4) This implies that the base SVE and SVE2 ACLE (00bet2) are now feature complete, meaning that all intrinsics are implemented in LLVM and Clang. Disclaimer: To implement the ACLE we have had to fix up many parts of LLVM to make it support scalable vectors. We have also used many target-specific intrinsics to reduce reliance on parts of LLVM where we know scalable vectors may not yet be handled properly (e.g. some transformation might drop the 'scalable' flag on a vector type). While we've done a best effort with the limited testing that is available to us, we're still working to improve the stability of the implementation. Additionally, Clang may print warnings that code may have miscompiled. We find this often to be a false alarm where the wrong interfaces have been used in LLVM and where resulting code is not actually incorrect. However, this warrants a bug report and investigation. If you find any bugs or issues, please raise them on bugs.llvm.org and let us know! Reviewers: rengolin, efriedma, david-arm, SjoerdMeijer Reviewed By: SjoerdMeijer Differential Revision: https://reviews.llvm.org/D81725
2020-06-24 23:52:41 +08:00
HasFullFP16 = 1;
HasSVE2 = 1;
HasSVE2BitPerm = 1;
}
[sve][acle] Enable feature macros for SVE ACLE extensions. Summary: The following feature macros have been added: __ARM_FEATURE_SVE_BF16 __ARM_FEATURE_SVE_MATMUL_INT8 __ARM_FEATURE_SVE_MATMUL_FP32 __ARM_FEATURE_SVE_MATMUL_FP64 The driver has been updated to enable them accordingly to the value of the target feature passed at command line. The SVE ACLE tests using the macros have been modified to work with the target feature instead of passing the macro at command line. Reviewers: sdesmalen, efriedma, c-rhodes, kmclaughlin, SjoerdMeijer, rengolin Subscribers: tschuett, kristof.beyls, rkruppe, psnobl, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D82623
2020-06-26 05:49:00 +08:00
if (Feature == "+f32mm") {
FPU |= SveMode;
HasMatmulFP32 = true;
}
if (Feature == "+f64mm") {
FPU |= SveMode;
HasMatmulFP64 = true;
}
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
if (Feature == "+crc")
[AArch64] Consistent types and naming for AArch64 target features (NFC) Differential Revision: https://reviews.llvm.org/D64415 Committed as obvious. llvm-svn: 366315
2019-07-17 19:24:37 +08:00
HasCRC = true;
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
if (Feature == "+crypto")
[AArch64] Consistent types and naming for AArch64 target features (NFC) Differential Revision: https://reviews.llvm.org/D64415 Committed as obvious. llvm-svn: 366315
2019-07-17 19:24:37 +08:00
HasCrypto = true;
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
if (Feature == "+strict-align")
[AArch64] Consistent types and naming for AArch64 target features (NFC) Differential Revision: https://reviews.llvm.org/D64415 Committed as obvious. llvm-svn: 366315
2019-07-17 19:24:37 +08:00
HasUnaligned = false;
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
if (Feature == "+v8.1a")
Update to use enum classes for various ARM *Kind enums Summary: This updates the relevant Clang parts for the LLVM change D35882. Reviewers: rengolin, chandlerc, javed.absar, rovka Reviewed By: rovka Subscribers: aemerson, cfe-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D35884 llvm-svn: 309289
2017-07-28 00:28:39 +08:00
ArchKind = llvm::AArch64::ArchKind::ARMV8_1A;
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
if (Feature == "+v8.2a")
Update to use enum classes for various ARM *Kind enums Summary: This updates the relevant Clang parts for the LLVM change D35882. Reviewers: rengolin, chandlerc, javed.absar, rovka Reviewed By: rovka Subscribers: aemerson, cfe-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D35884 llvm-svn: 309289
2017-07-28 00:28:39 +08:00
ArchKind = llvm::AArch64::ArchKind::ARMV8_2A;
[AArch64] Implement __jcvt intrinsic from Armv8.3-A The jcvt intrinsic defined in ACLE [1] is available when ARM_FEATURE_JCVT is defined. This change introduces the AArch64 intrinsic, wires it up to the instruction and a new clang builtin function. The __ARM_FEATURE_JCVT macro is now defined when an Armv8.3-A or higher target is used. I've implemented the target detection logic in Clang so that this feature is enabled for architectures from armv8.3-a onwards (so -march=armv8.4-a also enables this, for example). make check-all didn't show any new failures. [1] https://developer.arm.com/docs/101028/latest/data-processing-intrinsics Differential Revision: https://reviews.llvm.org/D64495 llvm-svn: 366197
2019-07-16 17:27:39 +08:00
if (Feature == "+v8.3a")
ArchKind = llvm::AArch64::ArchKind::ARMV8_3A;
if (Feature == "+v8.4a")
ArchKind = llvm::AArch64::ArchKind::ARMV8_4A;
if (Feature == "+v8.5a")
ArchKind = llvm::AArch64::ArchKind::ARMV8_5A;
[PATCH] [ARM] ARMv8.6-a command-line + BFloat16 Asm Support Summary: This patch introduces command-line support for the Armv8.6-a architecture and assembly support for BFloat16. Details can be found https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a in addition to the GCC patch for the 8..6-a CLI: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-11/msg02647.html In detail this patch - march options for armv8.6-a - BFloat16 assembly This is part of a patch series, starting with command-line and Bfloat16 assembly support. The subsequent patches will upstream intrinsics support for BFloat16, followed by Matrix Multiplication and the remaining Virtualization features of the armv8.6-a architecture. Based on work by: - labrinea - MarkMurrayARM - Luke Cheeseman - Javed Asbar - Mikhail Maltsev - Luke Geeson Reviewers: SjoerdMeijer, craig.topper, rjmccall, jfb, LukeGeeson Reviewed By: SjoerdMeijer Subscribers: stuij, kristof.beyls, hiraditya, dexonsmith, danielkiss, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D76062
2020-03-26 16:17:29 +08:00
if (Feature == "+v8.6a")
ArchKind = llvm::AArch64::ArchKind::ARMV8_6A;
[AArch64] Add CPU Cortex-R82 This adds support for -mcpu=cortex-r82. Some more information about this core can be found here: https://www.arm.com/products/silicon-ip-cpu/cortex-r/cortex-r82 One note about the system register: that is a bit of a refactoring because of small differences between v8.4-A AArch64 and v8-R AArch64. This is based on patches from Mark Murray and Mikhail Maltsev. Differential Revision: https://reviews.llvm.org/D88660
2020-10-01 22:47:31 +08:00
if (Feature == "+v8r")
ArchKind = llvm::AArch64::ArchKind::ARMV8R;
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
if (Feature == "+fullfp16")
[AArch64] Consistent types and naming for AArch64 target features (NFC) Differential Revision: https://reviews.llvm.org/D64415 Committed as obvious. llvm-svn: 366315
2019-07-17 19:24:37 +08:00
HasFullFP16 = true;
[AAch64] Add the __ARM_FEATURE_DOTPROD macro definition This matches what GCC does. https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aarch64/aarch64-c.c Differential Revision: https://reviews.llvm.org/D45544 llvm-svn: 330229
2018-04-18 06:38:40 +08:00
if (Feature == "+dotprod")
[AArch64] Consistent types and naming for AArch64 target features (NFC) Differential Revision: https://reviews.llvm.org/D64415 Committed as obvious. llvm-svn: 366315
2019-07-17 19:24:37 +08:00
HasDotProd = true;
[AArch64] Implement FP16FML intrinsics Generate the FP16FML intrinsics into arm_neon.h (AArch64 only for now). Add two new type modifiers to NeonEmitter to handle the new prototypes. Define __ARM_FEATURE_FP16FML when +fp16fml is enabled and guard the intrinsics with the macro in arm_neon.h. Based on a patch by Gao Yiling. Differential Revision: https://reviews.llvm.org/D53633 llvm-svn: 345344
2018-10-26 07:47:00 +08:00
if (Feature == "+fp16fml")
[AArch64] Consistent types and naming for AArch64 target features (NFC) Differential Revision: https://reviews.llvm.org/D64415 Committed as obvious. llvm-svn: 366315
2019-07-17 19:24:37 +08:00
HasFP16FML = true;
[AArch64] Add support for MTE intrinsics This provides intrinsics support for Memory Tagging Extension (MTE), which was introduced with the Armv8.5-a architecture. These intrinsics are available when __ARM_FEATURE_MEMORY_TAGGING is defined. Each intrinsic is described in detail in the ACLE Q1 2019 documentation: https://developer.arm.com/docs/101028/latest Reviewed By: Tim Nortover, David Spickett Differential Revision: https://reviews.llvm.org/D60485 llvm-svn: 359348
2019-04-27 05:08:11 +08:00
if (Feature == "+mte")
[AArch64] Consistent types and naming for AArch64 target features (NFC) Differential Revision: https://reviews.llvm.org/D64415 Committed as obvious. llvm-svn: 366315
2019-07-17 19:24:37 +08:00
HasMTE = true;
[AArch64] Add support for Transactional Memory Extension (TME) Re-commit r366322 after some fixes TME is a future architecture technology, documented in https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools https://developer.arm.com/docs/ddi0601/a More about the future architectures: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/new-technologies-for-the-arm-a-profile-architecture This patch adds support for the TME instructions TSTART, TTEST, TCOMMIT, and TCANCEL and the target feature/arch extension "tme". It also implements TME builtin functions, defined in ACLE Q2 2019 (https://developer.arm.com/docs/101028/latest) Differential Revision: https://reviews.llvm.org/D64416 Patch by Javed Absar and Momchil Velikov llvm-svn: 367428
2019-07-31 20:52:17 +08:00
if (Feature == "+tme")
HasTME = true;
[AArch64] Armv8.6-a Matrix Mult Assembly + Intrinsics This patch upstreams support for the Armv8.6-a Matrix Multiplication Extension. A summary of the features can be found here: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a This patch includes: - Assembly support for AArch64 only (no SVE or Neon) - Intrinsics Support for AArch64 Armv8.6a Matrix Multiplication Instructions (No bfloat16 matrix multiplication) No IR types or C Types are needed for this extension. This is part of a patch series, starting with BFloat16 support and the other components in the armv8.6a extension (in previous patches linked in phabricator) Based on work by: - Luke Geeson - Oliver Stannard - Luke Cheeseman Reviewers: ostannard, t.p.northover, rengolin, kmclaughlin Reviewed By: kmclaughlin Subscribers: kmclaughlin, kristof.beyls, hiraditya, danielkiss, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77871
2020-04-10 00:21:19 +08:00
if (Feature == "+i8mm")
HasMatMul = true;
[ARM] Add __bf16 as new Bfloat16 C Type Summary: This patch upstreams support for a new storage only bfloat16 C type. This type is used to implement primitive support for bfloat16 data, in line with the Bfloat16 extension of the Armv8.6-a architecture, as detailed here: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a The bfloat type, and its properties are specified in the Arm Architecture Reference Manual: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile In detail this patch: - introduces an opaque, storage-only C-type __bf16, which introduces a new bfloat IR type. This is part of a patch series, starting with command-line and Bfloat16 assembly support. The subsequent patches will upstream intrinsics support for BFloat16, followed by Matrix Multiplication and the remaining Virtualization features of the armv8.6-a architecture. The following people contributed to this patch: - Luke Cheeseman - Momchil Velikov - Alexandros Lamprineas - Luke Geeson - Simon Tatham - Ties Stuij Reviewers: SjoerdMeijer, rjmccall, rsmith, liutianle, RKSimon, craig.topper, jfb, LukeGeeson, fpetrogalli Reviewed By: SjoerdMeijer Subscribers: labrinea, majnemer, asmith, dexonsmith, kristof.beyls, arphaman, danielkiss, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D76077
2020-06-05 07:20:02 +08:00
if (Feature == "+bf16")
HasBFloat16 = true;
[AArch64] Define __ARM_FEATURE_{CRC32,ATOMICS} This patch implements the definition of __ARM_FEATURE_ATOMICS and fixes the missing definition of __ARM_FEATURE_CRC32 for Armv8.1-A. Differential Revision: https://reviews.llvm.org/D91438
2020-11-13 21:56:43 +08:00
if (Feature == "+lse")
HasLSE = true;
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
}
setDataLayout();
return true;
}
TargetInfo::CallingConvCheckResult
AArch64TargetInfo::checkCallingConvention(CallingConv CC) const {
switch (CC) {
case CC_C:
case CC_Swift:
case CC_PreserveMost:
case CC_PreserveAll:
case CC_OpenCLKernel:
[AArch64] Add aarch64_vector_pcs function attribute to Clang This is the Clang patch to complement the following LLVM patches: https://reviews.llvm.org/D51477 https://reviews.llvm.org/D51479 More information describing the vector ABI and procedure call standard can be found here: https://developer.arm.com/products/software-development-tools/\ hpc/arm-compiler-for-hpc/vector-function-abi Patch by Kerry McLaughlin. Reviewed By: rjmccall Differential Revision: https://reviews.llvm.org/D54425 llvm-svn: 347571
2018-11-27 00:38:37 +08:00
case CC_AArch64VectorCall:
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
case CC_Win64:
return CCCR_OK;
default:
return CCCR_Warning;
}
}
bool AArch64TargetInfo::isCLZForZeroUndef() const { return false; }
TargetInfo::BuiltinVaListKind AArch64TargetInfo::getBuiltinVaListKind() const {
return TargetInfo::AArch64ABIBuiltinVaList;
}
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
const char *const AArch64TargetInfo::GCCRegNames[] = {
// 32-bit Integer registers
"w0", "w1", "w2", "w3", "w4", "w5", "w6", "w7", "w8", "w9", "w10", "w11",
"w12", "w13", "w14", "w15", "w16", "w17", "w18", "w19", "w20", "w21", "w22",
"w23", "w24", "w25", "w26", "w27", "w28", "w29", "w30", "wsp",
// 64-bit Integer registers
"x0", "x1", "x2", "x3", "x4", "x5", "x6", "x7", "x8", "x9", "x10", "x11",
"x12", "x13", "x14", "x15", "x16", "x17", "x18", "x19", "x20", "x21", "x22",
"x23", "x24", "x25", "x26", "x27", "x28", "fp", "lr", "sp",
// 32-bit floating point regsisters
"s0", "s1", "s2", "s3", "s4", "s5", "s6", "s7", "s8", "s9", "s10", "s11",
"s12", "s13", "s14", "s15", "s16", "s17", "s18", "s19", "s20", "s21", "s22",
"s23", "s24", "s25", "s26", "s27", "s28", "s29", "s30", "s31",
// 64-bit floating point regsisters
"d0", "d1", "d2", "d3", "d4", "d5", "d6", "d7", "d8", "d9", "d10", "d11",
"d12", "d13", "d14", "d15", "d16", "d17", "d18", "d19", "d20", "d21", "d22",
"d23", "d24", "d25", "d26", "d27", "d28", "d29", "d30", "d31",
[SVE][Inline-Asm] Add support to specify SVE registers in the clobber list Adds the SVE vector and predicate registers to the list of known registers. Patch by Kerry McLaughlin. Reviewers: erichkeane, sdesmalen, rengolin Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D64739 llvm-svn: 366878
2019-07-24 16:42:34 +08:00
// Neon vector registers
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
"v0", "v1", "v2", "v3", "v4", "v5", "v6", "v7", "v8", "v9", "v10", "v11",
"v12", "v13", "v14", "v15", "v16", "v17", "v18", "v19", "v20", "v21", "v22",
[SVE][Inline-Asm] Add support to specify SVE registers in the clobber list Adds the SVE vector and predicate registers to the list of known registers. Patch by Kerry McLaughlin. Reviewers: erichkeane, sdesmalen, rengolin Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D64739 llvm-svn: 366878
2019-07-24 16:42:34 +08:00
"v23", "v24", "v25", "v26", "v27", "v28", "v29", "v30", "v31",
// SVE vector registers
"z0", "z1", "z2", "z3", "z4", "z5", "z6", "z7", "z8", "z9", "z10",
"z11", "z12", "z13", "z14", "z15", "z16", "z17", "z18", "z19", "z20", "z21",
"z22", "z23", "z24", "z25", "z26", "z27", "z28", "z29", "z30", "z31",
// SVE predicate registers
"p0", "p1", "p2", "p3", "p4", "p5", "p6", "p7", "p8", "p9", "p10",
"p11", "p12", "p13", "p14", "p15"
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
};
ArrayRef<const char *> AArch64TargetInfo::getGCCRegNames() const {
return llvm::makeArrayRef(GCCRegNames);
}
const TargetInfo::GCCRegAlias AArch64TargetInfo::GCCRegAliases[] = {
[AArch64]: Add support for parsing rN registers. Summary: Allow rN registers to be simply parsed as correspoing xN registers. The "register ... asm("rN")" is an command to the compiler's register allocator, not an operand to any individual assembly instruction. GCC documents this syntax as "...the name of the register that should be used." This is needed to support the changes in Linux kernel (see https://lkml.org/lkml/2018/3/1/268 ) Note: This will add support only for the limited use case of register ... asm("rN"). Any other uses that make rN leak into assembly are not supported. Reviewers: kristof.beyls, rengolin, peter.smith, t.p.northover Reviewed By: peter.smith Subscribers: javed.absar, eraman, cfe-commits, srhines Differential Revision: https://reviews.llvm.org/D44815 llvm-svn: 328829
2018-03-30 05:11:15 +08:00
{{"w31"}, "wsp"},
{{"x31"}, "sp"},
// GCC rN registers are aliases of xN registers.
{{"r0"}, "x0"},
{{"r1"}, "x1"},
{{"r2"}, "x2"},
{{"r3"}, "x3"},
{{"r4"}, "x4"},
{{"r5"}, "x5"},
{{"r6"}, "x6"},
{{"r7"}, "x7"},
{{"r8"}, "x8"},
{{"r9"}, "x9"},
{{"r10"}, "x10"},
{{"r11"}, "x11"},
{{"r12"}, "x12"},
{{"r13"}, "x13"},
{{"r14"}, "x14"},
{{"r15"}, "x15"},
{{"r16"}, "x16"},
{{"r17"}, "x17"},
{{"r18"}, "x18"},
{{"r19"}, "x19"},
{{"r20"}, "x20"},
{{"r21"}, "x21"},
{{"r22"}, "x22"},
{{"r23"}, "x23"},
{{"r24"}, "x24"},
{{"r25"}, "x25"},
{{"r26"}, "x26"},
{{"r27"}, "x27"},
{{"r28"}, "x28"},
{{"r29", "x29"}, "fp"},
{{"r30", "x30"}, "lr"},
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
// The S/D/Q and W/X registers overlap, but aren't really aliases; we
// don't want to substitute one of these for a different-sized one.
};
ArrayRef<TargetInfo::GCCRegAlias> AArch64TargetInfo::getGCCRegAliases() const {
return llvm::makeArrayRef(GCCRegAliases);
}
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
bool AArch64TargetInfo::validateAsmConstraint(
const char *&Name, TargetInfo::ConstraintInfo &Info) const {
switch (*Name) {
default:
return false;
case 'w': // Floating point and SIMD registers (V0-V31)
Info.setAllowsRegister();
return true;
case 'I': // Constant that can be used with an ADD instruction
case 'J': // Constant that can be used with a SUB instruction
case 'K': // Constant that can be used with a 32-bit logical instruction
case 'L': // Constant that can be used with a 64-bit logical instruction
case 'M': // Constant that can be used as a 32-bit MOV immediate
case 'N': // Constant that can be used as a 64-bit MOV immediate
case 'Y': // Floating point constant zero
case 'Z': // Integer constant zero
return true;
case 'Q': // A memory reference with base register and no offset
Info.setAllowsMemory();
return true;
case 'S': // A symbolic address
Info.setAllowsRegister();
return true;
case 'U':
[SVE][Inline-Asm] Add constraints for SVE ACLE types Summary: Adds the constraints described below to ensure that we can tie variables of SVE ACLE types to operands in inline-asm: - y: SVE registers Z0-Z7 - Upl: One of the low eight SVE predicate registers (P0-P7) - Upa: Full range of SVE predicate registers (P0-P15) Reviewers: sdesmalen, huntergr, rovka, cameron.mcinally, efriedma, rengolin Reviewed By: efriedma Subscribers: miyuki, tschuett, rkruppe, psnobl, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D75690
2020-03-17 18:27:29 +08:00
if (Name[1] == 'p' && (Name[2] == 'l' || Name[2] == 'a')) {
// SVE predicate registers ("Upa"=P0-15, "Upl"=P0-P7)
Info.setAllowsRegister();
Name += 2;
return true;
}
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
// Ump: A memory address suitable for ldp/stp in SI, DI, SF and DF modes.
// Utf: A memory address suitable for ldp/stp in TF mode.
// Usa: An absolute symbolic address.
// Ush: The high part (bits 32:12) of a pc-relative symbolic address.
[SVE][Inline-Asm] Add constraints for SVE ACLE types Summary: Adds the constraints described below to ensure that we can tie variables of SVE ACLE types to operands in inline-asm: - y: SVE registers Z0-Z7 - Upl: One of the low eight SVE predicate registers (P0-P7) - Upa: Full range of SVE predicate registers (P0-P15) Reviewers: sdesmalen, huntergr, rovka, cameron.mcinally, efriedma, rengolin Reviewed By: efriedma Subscribers: miyuki, tschuett, rkruppe, psnobl, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D75690
2020-03-17 18:27:29 +08:00
// Better to return an error saying that it's an unrecognised constraint
// even if this is a valid constraint in gcc.
return false;
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
case 'z': // Zero register, wzr or xzr
Info.setAllowsRegister();
return true;
case 'x': // Floating point and SIMD registers (V0-V15)
Info.setAllowsRegister();
return true;
[SVE][Inline-Asm] Add constraints for SVE ACLE types Summary: Adds the constraints described below to ensure that we can tie variables of SVE ACLE types to operands in inline-asm: - y: SVE registers Z0-Z7 - Upl: One of the low eight SVE predicate registers (P0-P7) - Upa: Full range of SVE predicate registers (P0-P15) Reviewers: sdesmalen, huntergr, rovka, cameron.mcinally, efriedma, rengolin Reviewed By: efriedma Subscribers: miyuki, tschuett, rkruppe, psnobl, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D75690
2020-03-17 18:27:29 +08:00
case 'y': // SVE registers (V0-V7)
Info.setAllowsRegister();
return true;
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
}
return false;
}
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
bool AArch64TargetInfo::validateConstraintModifier(
StringRef Constraint, char Modifier, unsigned Size,
std::string &SuggestedModifier) const {
// Strip off constraint modifiers.
while (Constraint[0] == '=' || Constraint[0] == '+' || Constraint[0] == '&')
Constraint = Constraint.substr(1);
switch (Constraint[0]) {
default:
return true;
case 'z':
case 'r': {
switch (Modifier) {
case 'x':
case 'w':
// For now assume that the person knows what they're
// doing with the modifier.
return true;
default:
// By default an 'r' constraint will be in the 'x'
// registers.
if (Size == 64)
return true;
SuggestedModifier = "w";
return false;
}
}
}
}
const char *AArch64TargetInfo::getClobbers() const { return ""; }
int AArch64TargetInfo::getEHDataRegisterNumber(unsigned RegNo) const {
if (RegNo == 0)
return 0;
if (RegNo == 1)
return 1;
return -1;
}
AArch64: add arm64_32 support to Clang.
2018-09-18 17:34:39 +08:00
bool AArch64TargetInfo::hasInt128Type() const { return true; }
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
AArch64leTargetInfo::AArch64leTargetInfo(const llvm::Triple &Triple,
const TargetOptions &Opts)
: AArch64TargetInfo(Triple, Opts) {}
void AArch64leTargetInfo::setDataLayout() {
AArch64: add arm64_32 support to Clang.
2018-09-18 17:34:39 +08:00
if (getTriple().isOSBinFormatMachO()) {
if(getTriple().isArch32Bit())
resetDataLayout("e-m:o-p:32:32-i64:64-i128:128-n32:64-S128");
else
resetDataLayout("e-m:o-i64:64-i128:128-n32:64-S128");
} else
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
resetDataLayout("e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128");
}
void AArch64leTargetInfo::getTargetDefines(const LangOptions &Opts,
MacroBuilder &Builder) const {
Builder.defineMacro("__AARCH64EL__");
AArch64TargetInfo::getTargetDefines(Opts, Builder);
}
AArch64beTargetInfo::AArch64beTargetInfo(const llvm::Triple &Triple,
const TargetOptions &Opts)
: AArch64TargetInfo(Triple, Opts) {}
void AArch64beTargetInfo::getTargetDefines(const LangOptions &Opts,
MacroBuilder &Builder) const {
Builder.defineMacro("__AARCH64EB__");
Builder.defineMacro("__AARCH_BIG_ENDIAN");
Builder.defineMacro("__ARM_BIG_ENDIAN");
AArch64TargetInfo::getTargetDefines(Opts, Builder);
}
void AArch64beTargetInfo::setDataLayout() {
assert(!getTriple().isOSBinFormatMachO());
resetDataLayout("E-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128");
}
[AArch64] Add support for a MinGW AArch64 target Differential Revision: https://reviews.llvm.org/D36364 llvm-svn: 310798
2017-08-14 03:42:17 +08:00
WindowsARM64TargetInfo::WindowsARM64TargetInfo(const llvm::Triple &Triple,
const TargetOptions &Opts)
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
: WindowsTargetInfo<AArch64leTargetInfo>(Triple, Opts), Triple(Triple) {
// This is an LLP64 platform.
// int:4, long:4, long long:8, long double:8.
IntWidth = IntAlign = 32;
LongWidth = LongAlign = 32;
DoubleAlign = LongLongAlign = 64;
LongDoubleWidth = LongDoubleAlign = 64;
LongDoubleFormat = &llvm::APFloat::IEEEdouble();
IntMaxType = SignedLongLong;
Int64Type = SignedLongLong;
SizeType = UnsignedLongLong;
PtrDiffType = SignedLongLong;
IntPtrType = SignedLongLong;
}
[AArch64] Add support for a MinGW AArch64 target Differential Revision: https://reviews.llvm.org/D36364 llvm-svn: 310798
2017-08-14 03:42:17 +08:00
void WindowsARM64TargetInfo::setDataLayout() {
Fix the data layout mangling specification for 'arm64-pc-win32-macho' rdar://problem/70410504
2020-11-11 10:36:10 +08:00
resetDataLayout(Triple.isOSBinFormatMachO()
? "e-m:o-i64:64-i128:128-n32:64-S128"
: "e-m:w-p:64:64-i32:32-i64:64-i128:128-n32:64-S128");
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
}
TargetInfo::BuiltinVaListKind
[AArch64] Add support for a MinGW AArch64 target Differential Revision: https://reviews.llvm.org/D36364 llvm-svn: 310798
2017-08-14 03:42:17 +08:00
WindowsARM64TargetInfo::getBuiltinVaListKind() const {
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
return TargetInfo::CharPtrBuiltinVaList;
}
[AArch64] Ignore stdcall and similar on aarch64/windows This is similar to what's done on arm and x86_64, where these calling conventions are silently ignored, as in SVN r245076. Differential Revision: https://reviews.llvm.org/D36105 llvm-svn: 310303
2017-08-08 04:52:04 +08:00
TargetInfo::CallingConvCheckResult
[AArch64] Add support for a MinGW AArch64 target Differential Revision: https://reviews.llvm.org/D36364 llvm-svn: 310798
2017-08-14 03:42:17 +08:00
WindowsARM64TargetInfo::checkCallingConvention(CallingConv CC) const {
[AArch64] Ignore stdcall and similar on aarch64/windows This is similar to what's done on arm and x86_64, where these calling conventions are silently ignored, as in SVN r245076. Differential Revision: https://reviews.llvm.org/D36105 llvm-svn: 310303
2017-08-08 04:52:04 +08:00
switch (CC) {
case CC_X86StdCall:
case CC_X86ThisCall:
case CC_X86FastCall:
case CC_X86VectorCall:
return CCCR_Ignore;
case CC_C:
case CC_OpenCLKernel:
Basic: support Preserve{Most,All} CC on Windows Add support for the `preserve_mostcc` and `preserve_allcc` on Windows x86_64 and AArch64. This is used by Swift. llvm-svn: 314236
2017-09-27 03:26:01 +08:00
case CC_PreserveMost:
case CC_PreserveAll:
ARM, AArch64: support `__attribute__((__swiftcall__))` Support the Swift calling convention on Windows ARM and AArch64. Both of these conform to the AAPCS, AAPCS64 calling convention, and LLVM has been adjusted to account for the register usage. Ensure that the frontend passes this into the backend. This allows the swift runtime to be built for Windows. llvm-svn: 348454
2018-12-06 11:28:37 +08:00
case CC_Swift:
[AArch64] Ignore stdcall and similar on aarch64/windows This is similar to what's done on arm and x86_64, where these calling conventions are silently ignored, as in SVN r245076. Differential Revision: https://reviews.llvm.org/D36105 llvm-svn: 310303
2017-08-08 04:52:04 +08:00
case CC_Win64:
return CCCR_OK;
default:
return CCCR_Warning;
}
}
[AArch64] Add support for a MinGW AArch64 target Differential Revision: https://reviews.llvm.org/D36364 llvm-svn: 310798
2017-08-14 03:42:17 +08:00
MicrosoftARM64TargetInfo::MicrosoftARM64TargetInfo(const llvm::Triple &Triple,
const TargetOptions &Opts)
: WindowsARM64TargetInfo(Triple, Opts) {
TheCXXABI.set(TargetCXXABI::Microsoft);
}
void MicrosoftARM64TargetInfo::getTargetDefines(const LangOptions &Opts,
MacroBuilder &Builder) const {
De-templatize non-dependent VS macro logic, NFC These macro definitions don't depend on the template parameter, so they don't need to be part of the template. Move them to a .cpp file. llvm-svn: 365556
2019-07-10 04:57:28 +08:00
WindowsARM64TargetInfo::getTargetDefines(Opts, Builder);
Builder.defineMacro("_M_ARM64", "1");
[AArch64] Add support for a MinGW AArch64 target Differential Revision: https://reviews.llvm.org/D36364 llvm-svn: 310798
2017-08-14 03:42:17 +08:00
}
[ARM64] [Windows] Follow MS X86_64 C++ ABI when passing structs Summary: Microsoft's C++ object model for ARM64 is the same as that for X86_64. For example, small structs with non-trivial copy constructors or virtual function tables are passed indirectly. Currently, they are passed in registers when compiled with clang. Reviewers: rnk, mstorsjo, TomTan, haripul, javed.absar Reviewed By: rnk, mstorsjo Subscribers: kristof.beyls, chrib, llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D49770 llvm-svn: 338076
2018-07-27 06:18:28 +08:00
TargetInfo::CallingConvKind
MicrosoftARM64TargetInfo::getCallingConvKind(bool ClangABICompat4) const {
return CCK_MicrosoftWin64;
}
[COFF, ARM64] Align global symbol by size for ARM64 MSVC ABI According to alignment section in below ARM64 ABI document, MSVC could increase alignment of global data based on its total size. Clang doesn't do this. Compile the same symbol into different alignments by Clang and MSVC could cause link error because some instruction encodings, like 64-bit LDR/STR with immediate, require the target to be 8 bytes aligned, and linker could choose code stream with such LDR/STR instruction from MSVC and 4 bytes aligned data from Clang into final image, which actually cannot be linked together (see https://bugs.llvm.org/show_bug.cgi?id=41506 for more details). https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2019#alignment Differential Revision: https://reviews.llvm.org/D61225 llvm-svn: 359744
2019-05-02 08:38:14 +08:00
unsigned MicrosoftARM64TargetInfo::getMinGlobalAlign(uint64_t TypeSize) const {
unsigned Align = WindowsARM64TargetInfo::getMinGlobalAlign(TypeSize);
// MSVC does size based alignment for arm64 based on alignment section in
// below document, replicate that to keep alignment consistent with object
// files compiled by MSVC.
// https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions
if (TypeSize >= 512) { // TypeSize >= 64 bytes
Align = std::max(Align, 128u); // align type at least 16 bytes
} else if (TypeSize >= 64) { // TypeSize >= 8 bytes
Align = std::max(Align, 64u); // align type at least 8 butes
} else if (TypeSize >= 16) { // TypeSize >= 2 bytes
Align = std::max(Align, 32u); // align type at least 4 bytes
}
return Align;
}
[AArch64] Add support for a MinGW AArch64 target Differential Revision: https://reviews.llvm.org/D36364 llvm-svn: 310798
2017-08-14 03:42:17 +08:00
MinGWARM64TargetInfo::MinGWARM64TargetInfo(const llvm::Triple &Triple,
const TargetOptions &Opts)
: WindowsARM64TargetInfo(Triple, Opts) {
TheCXXABI.set(TargetCXXABI::GenericAArch64);
}
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
DarwinAArch64TargetInfo::DarwinAArch64TargetInfo(const llvm::Triple &Triple,
const TargetOptions &Opts)
: DarwinTargetInfo<AArch64leTargetInfo>(Triple, Opts) {
Int64Type = SignedLongLong;
AArch64: add arm64_32 support to Clang.
2018-09-18 17:34:39 +08:00
if (getTriple().isArch32Bit())
IntMaxType = SignedLongLong;
WCharType = SignedInt;
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
UseSignedCharForObjCBool = false;
LongDoubleWidth = LongDoubleAlign = SuitableAlign = 64;
LongDoubleFormat = &llvm::APFloat::IEEEdouble();
AArch64: add arm64_32 support to Clang.
2018-09-18 17:34:39 +08:00
UseZeroLengthBitfieldAlignment = false;
if (getTriple().isArch32Bit()) {
UseBitFieldTypeAlignment = false;
ZeroLengthBitfieldBoundary = 32;
UseZeroLengthBitfieldAlignment = true;
TheCXXABI.set(TargetCXXABI::WatchOS);
} else
[mac/arm] Fix rtti codegen tests when running on an arm mac shouldRTTIBeUnique() returns false for iOS64CXXABI, which causes RTTI objects to be emitted hidden. Update two tests that didn't expect this to happen for the default triple. Also rename iOS64CXXABI to AppleARM64CXXABI, since it's used for arm64-apple-macos triples too. Part of PR46644. Differential Revision: https://reviews.llvm.org/D91904
2020-12-03 22:11:03 +08:00
TheCXXABI.set(TargetCXXABI::AppleARM64);
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
}
void DarwinAArch64TargetInfo::getOSDefines(const LangOptions &Opts,
const llvm::Triple &Triple,
MacroBuilder &Builder) const {
Builder.defineMacro("__AARCH64_SIMD__");
AArch64: add arm64_32 support to Clang.
2018-09-18 17:34:39 +08:00
if (Triple.isArch32Bit())
Builder.defineMacro("__ARM64_ARCH_8_32__");
else
Builder.defineMacro("__ARM64_ARCH_8__");
AArch64 & ARM: move TargetInfo functions from .h to .cpp file. NFC. Most of them are virtual anyway, and the few remaining ones can move to the .cpp for consistency. llvm-svn: 308898
2017-07-25 01:06:23 +08:00
Builder.defineMacro("__ARM_NEON__");
Builder.defineMacro("__LITTLE_ENDIAN__");
Builder.defineMacro("__REGISTER_PREFIX__", "");
Builder.defineMacro("__arm64", "1");
Builder.defineMacro("__arm64__", "1");
getDarwinDefines(Builder, Opts, Triple, PlatformName, PlatformMinVersion);
}
TargetInfo::BuiltinVaListKind
DarwinAArch64TargetInfo::getBuiltinVaListKind() const {
return TargetInfo::CharPtrBuiltinVaList;
}
// 64-bit RenderScript is aarch64
RenderScript64TargetInfo::RenderScript64TargetInfo(const llvm::Triple &Triple,
const TargetOptions &Opts)
: AArch64leTargetInfo(llvm::Triple("aarch64", Triple.getVendorName(),
Triple.getOSName(),
Triple.getEnvironmentName()),
Opts) {
IsRenderScriptTarget = true;
}
void RenderScript64TargetInfo::getTargetDefines(const LangOptions &Opts,
MacroBuilder &Builder) const {
Builder.defineMacro("__RENDERSCRIPT__");
AArch64leTargetInfo::getTargetDefines(Opts, Builder);
}