This fixed PR#48894 for AArch64. The issue has been fixed for Arm in
https://reviews.llvm.org/D95872
The following rules apply to -Wa,-march with this change:
- Only compiler options apply to non assembly files
- Compiler and assembler options apply to assembly files
- For assembly files, we prefer the assembler option(s) if we have both kinds of option
- Of the options that apply (or are preferred), the last value wins (it's not additive)
Reviewed By: DavidSpickett, nickdesaulniers
Differential Revision: https://reviews.llvm.org/D103184
Linker scripts might not handle COMDAT sections. SLSHardeing adds
new section for each __llvm_slsblr_thunk_xN. This new option allows
the generation of the thunks into the normal text section to handle these
exceptional cases.
,comdat or ,noncomdat can be added to harden-sls to control the codegen.
-mharden-sls=[all|retbr|blr],nocomdat.
Reviewed By: kristof.beyls
Differential Revision: https://reviews.llvm.org/D100546
This demotes the apple-a12 CPU selection for arm64e to just be the
last-resort default. Concretely, this means:
- an explicitly-specified -mcpu will override the arm64e default;
a user could potentially pick an invalid CPU that doesn't have
v8.3a support, but that's not a major problem anymore
- arm64e-apple-macos (and variants) will pick apple-m1 instead of
being forced to apple-a12.
apple-m1 has the same level of ISA support as apple-a14,
so this is a straightforward mechanical change. However, that
also means this inherits apple-a14's v8.5a+nobti quirkiness.
rdar://68287159
This introduces command-line support for the 'armv8.7-a' architecture name
(and an alias without the '-', as usual), and for the 'ls64' extension name.
Based on patches written by Simon Tatham.
Reviewed By: ostannard
Differential Revision: https://reviews.llvm.org/D91776
Remove target features crypto for Cortex-R82, because it doesn't have any, and
add LSE which was missing while we are at it.
This also removes crypto from the v8-R architecture description because that
aligns better with GCC and so far none of the R-cores have implemented crypto,
so is probably a more sensible default.
Differential Revision: https://reviews.llvm.org/D91994
... and give more guidance to users.
If specifying -msve-vector-bits on a non-SVE target, clang would say:
error: '-msve-vector-bits' is not supported without SVE enabled
1. The driver lacks logic for "implied features".
This would result in this error being raised for -march=...+sve2,
even though +sve2 implies +sve.
2. Feature implication is well modelled in LLVM, so push the error down
the stack.
3. Hint to the user what flag they need to consider setting.
Now clang fails later, when the feature is used, saying:
aarch64-sve-vector-bits.c:42:41: error: 'arm_sve_vector_bits' attribute is not supported on targets missing 'sve'; specify an appropriate -march= or -mcpu=
typedef svint32_t noflag __attribute__((arm_sve_vector_bits(256)));
Move clang/test/Sema/{neon => arm}-vector-types-support.c and put tests for
this warning together in one place.
Reviewed By: sdesmalen
Differential Revision: https://reviews.llvm.org/D92487
This also teaches MachO writers/readers about the MachO cpu subtype,
beyond the minimal subtype reader support present at the moment.
This also defines a preprocessor macro to allow users to distinguish
__arm64__ from __arm64e__.
arm64e defaults to an "apple-a12" CPU, which supports v8.3a, allowing
pointer-authentication codegen.
It also currently defaults to ios14 and macos11.
Differential Revision: https://reviews.llvm.org/D87095
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
No real action is taken for a value of scalable but it provides a
route to disable an earlier specification and is effectively its
default value when omitted.
Patch also removes an "unused variable" warning.
Differential Revision: https://reviews.llvm.org/D84021
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
The accepted options to -mharden-sls= are:
* all: enable all mitigations against Straight Line Speculation that are
implemented.
* none: disable all mitigations against Straight Line Speculation.
* retbr: enable the mitigation against Straight Line Speculation for RET
and BR instructions.
* blr: enable the mitigation against Straight Line Speculation for BLR
instructions.
Differential Revision: https://reviews.llvm.org/D81404
Add support for reserving LR in:
* the driver through `-ffixed-x30`
* cc1 through `-target-feature +reserve-x30`
* the backend through `-mattr=+reserve-x30`
* a subtarget feature `reserve-x30`
the same way we're doing for the other registers.
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:
- Command line options to enable these features with +i8mm, +f32mm, or f64mm
Note: +f32mm and +f64mm are optional and so are not enabled by default
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: t.p.northover, DavidSpickett
Reviewed By: DavidSpickett
Subscribers: DavidSpickett, ostannard, kristof.beyls, danielkiss,
cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77875
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
Apple's CPUs are called A7-A13 in official communication, occasionally with
weird suffixes which we probably don't need to care about. This adds each one
and describes its features. It also switches the default CPU to the canonical
name for Cyclone, but leaves legacy support in so that existing bitcode still
compiles.
Works on this dependency chain:
ArrayRef.h ->
Hashing.h -> --CUT--
Host.h ->
StringMap.h / StringRef.h
ArrayRef is very popular, but Host.h is rarely needed. Move the
IsBigEndianHost constant to SwapByteOrder.h. Clients of that header are
more likely to need it.
llvm-svn: 375316
Add an -mtp=el[0-3] option to select which of the AArch64 thread ID registers
will be used for the TLS base pointer.
This is a followup to rL356657 which added subtarget features to enable
accesses to the privileged thread ID registers.
Patch by Philip Derrin!
Differential revision: https://reviews.llvm.org/D59631
llvm-svn: 357250
This is a follow up to D48580 and D48581 which allows reserving
arbitrary general purpose registers with the exception of registers
with special purpose (X8, X16-X18, X29, X30) and registers used by LLVM
(X0, X19). This change also generalizes some of the existing logic to
rely entirely on values generated from tablegen.
Differential Revision: https://reviews.llvm.org/D56305
llvm-svn: 353957
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
is not specified
The -target option allows the user to specify the build target using LLVM
triple. The triple includes the arch, and so the -arch option is redundant.
This should work just as well without the -arch. However, the driver has a bug
in which it doesn't target the "Cyclone" CPU for darwin if -target is used
without -arch. This commit fixes this issue.
rdar://46743182
Differential Revision: https://reviews.llvm.org/D55731
llvm-svn: 349382
For AArch64, crypto means:
- sm4 + sha3 + sha2 + aes for Armv8.4-A and up, and
- sha2 + aes for Armv8.3-A and earlier.
For AArch32:
Crypto means sha2 + aes, because the Armv8.2-A crypto instructions
were added to AArch64 only.
Differential Revision: https://reviews.llvm.org/D50179
llvm-svn: 343758
Summary:
Making X[8-15,18] registers call-saved is used to support
CONFIG_ARM64_LSE_ATOMICS in Linux kernel.
Signed-off-by: Tri Vo <trong@android.com>
Reviewers: srhines, nickdesaulniers, javed.absar
Reviewed By: nickdesaulniers
Subscribers: kristof.beyls, jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D52399
llvm-svn: 342990
Armv8.4-A adds a few FP16 instructions that can optionally be implemented
in CPUs of Armv8.2-A and above.
This patch adds a feature to clang to permit selection of these
instructions. This interacts with the +fp16 option as follows:
Prior to Armv8.4-A:
*) +fp16fml implies +fp16
*) +nofp16 implies +nofp16fml
From Armv8.4-A:
*) The above conditions apply, additionally: +fp16 implies +fp16fml
Patch by Bernard Ogden.
Differential Revision: https://reviews.llvm.org/D50229
llvm-svn: 342862
Summary: Reserving registers x1-7 is used to support CONFIG_ARM64_LSE_ATOMICS in Linux kernel. This change adds support for reserving registers x1 through x7.
Reviewers: javed.absar, efriedma, nickdesaulniers, srhines, phosek
Reviewed By: nickdesaulniers
Subscribers: manojgupta, jfb, cfe-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D48581
llvm-svn: 342100
This patches adds support for passing -mcpu=native for AArch64. It will
get turned into the host CPU name, before we get the target features.
CPU = native is handled in a similar fashion in
getAArch64MicroArchFetauresFromMtune and getAArch64TargetCPU already.
Having a good test case for this is hard, as it depends on the host CPU
of the machine running the test. But we can check that native has been
replaced with something else.
When cross-compiling, we will get a CPU name from the host architecture
and get ` the clang compiler does not support '-mcpu=native'` as error
message, which seems reasonable to me.
Reviewers: rengolin, peter.smith, dlj, javed.absar, t.p.northover
Reviewed By: peter.smith
Tags: #clang
Differential Revision: https://reviews.llvm.org/D48931
llvm-svn: 336429
Register x20 is a callee-saved register which may be used for other
purposes in certain contexts, for example to hold special variables
within the kernel. This change adds support for reserving this register
both to frontend and backend to make this register usable for these
purposes.
Differential Revision: https://reviews.llvm.org/D46552
llvm-svn: 334531
When -mtune is used on AArch64 the -target-cpu is passed the value of the
cpu given to -mtune. As well as setting micro-architectural features of the
-mtune cpu, this will also add the architectural features such as support
for instructions. This can result in the backend using instructions that
are supported in the -mtune cpu but not supported in the target
architecture. For example use of the v8.1-a LSE extensions with -march=v8.
This change removes the setting of -target-cpu for -mtune, the -mcpu must
be used to set -target-cpu. This has the effect of removing all non-hard
coded benefits of mtune but it does produce correct output when -mtune cpu
with a later architecture than v8 is used.
Fixes PR34625
Differential Revision: https://reviews.llvm.org/D39179
llvm-svn: 316424
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
Jian Cai