This compensates for 8f0c901c1a which enabled
-Wunused-command-line-argument for unimplemented -mtune= in the generic code.
Ignoring -mtune= appears to be longstanding and the error-free behavior in the
presence of -Werror is unfortunately relied on by the Linux kernel's arm and
powerpc ports. Ignore the warnings for the upcoming 15.0.0 branch and will
implement functionality to fill the test gap soon.
Link: https://github.com/ClangBuiltLinux/linux/issues/1674
err_drv_clang_unsupported is for a Clang unsupported option (any value is rejected).
err_drv_unsupported_option_argument is for an unsupported value (other values may be supported).
Currently the a AAPCS compliant frame record is not always created for
functions when it should. Although a consistent frame record might not
be required in some cases, there are still scenarios where applications
may want to make use of the call hierarchy made available trough it.
In order to enable the use of AAPCS compliant frame records whilst keep
backwards compatibility, this patch introduces a new command-line option
(`-mframe-chain=[none|aapcs|aapcs+leaf]`) for Aarch32 and Thumb backends.
The option allows users to explicitly select when to use it, and is also
useful to ensure the extra overhead introduced by the frame records is
only introduced when necessary, in particular for Thumb targets.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D125094
Currently the a AAPCS compliant frame record is not always created for
functions when it should. Although a consistent frame record might not
be required in some cases, there are still scenarios where applications
may want to make use of the call hierarchy made available trough it.
In order to enable the use of AAPCS compliant frame records whilst keep
backwards compatibility, this patch introduces a new command-line option
(`-mframe-chain=[none|aapcs|aapcs+leaf]`) for Aarch32 and Thumb backends.
The option allows users to explicitly select when to use it, and is also
useful to ensure the extra overhead introduced by the frame records is
only introduced when necessary, in particular for Thumb targets.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D125094
Currently the a AAPCS compliant frame record is not always created for
functions when it should. Although a consistent frame record might not
be required in some cases, there are still scenarios where applications
may want to make use of the call hierarchy made available trough it.
In order to enable the use of AAPCS compliant frame records whilst keep
backwards compatibility, this patch introduces a new command-line option
(`-mframe-chain=[none|aapcs|aapcs+leaf]`) for Aarch32 and Thumb backends.
The option allows users to explicitly select when to use it, and is also
useful to ensure the extra overhead introduced by the frame records is
only introduced when necessary, in particular for Thumb targets.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D125094
Update the diagnostic in D81404: the convention is to use
err_drv_unsupported_option_argument instead of adding a new diagnostic for every
option.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D126511
This adds a late Machine Pass to work around a Cortex CPU Erratum
affecting Cortex-A57 and Cortex-A72:
- Cortex-A57 Erratum 1742098
- Cortex-A72 Erratum 1655431
The pass inserts instructions to make the inputs to the fused AES
instruction pairs no longer trigger the erratum. Here the pass errs on
the side of caution, inserting the instructions wherever we cannot prove
that the inputs came from a safe instruction.
The pass is used:
- for Cortex-A57 and Cortex-A72,
- for "generic" cores (which are used when using `-march=`),
- when the user specifies `-mfix-cortex-a57-aes-1742098` or
`mfix-cortex-a72-aes-1655431` in the command-line arguments to clang.
Reviewed By: dmgreen, simon_tatham
Differential Revision: https://reviews.llvm.org/D119720
The cleanup was manual, but assisted by "include-what-you-use". It consists in
1. Removing unused forward declaration. No impact expected.
2. Removing unused headers in .cpp files. No impact expected.
3. Removing unused headers in .h files. This removes implicit dependencies and
is generally considered a good thing, but this may break downstream builds.
I've updated llvm, clang, lld, lldb and mlir deps, and included a list of the
modification in the second part of the commit.
4. Replacing header inclusion by forward declaration. This has the same impact
as 3.
Notable changes:
- llvm/Support/TargetParser.h no longer includes llvm/Support/AArch64TargetParser.h nor llvm/Support/ARMTargetParser.h
- llvm/Support/TypeSize.h no longer includes llvm/Support/WithColor.h
- llvm/Support/YAMLTraits.h no longer includes llvm/Support/Regex.h
- llvm/ADT/SmallVector.h no longer includes llvm/Support/MemAlloc.h nor llvm/Support/ErrorHandling.h
You may need to add some of these headers in your compilation units, if needs be.
As an hint to the impact of the cleanup, running
clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Support/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
before: 8000919 lines
after: 7917500 lines
Reduced dependencies also helps incremental rebuilds and is more ccache
friendly, something not shown by the above metric :-)
Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup/5831
Added warning for potential cases of
unaligned access when option
-mno-unaligned-access has been specified
Differential Revision: https://reviews.llvm.org/D116221
Building -march=armv6k Linux kernels with -mtp=cp15 fails to
compile:
error: hardware TLS register is not supported for the arm
sub-architecture
@ardb found docs for ARM1176JZF-S (ARMv6K) that reference hard thread
pointer.
Relax our ARMv6 check for cases where we're targeting ARM via -marm (vs
Thumb1 via -mthumb). This more closely matches the KConfig requirements
for where we plan to use these (ie. ARMv6K, ARMv7 (arm or thumb2)).
As @peter.smith mentions:
on armv5 we can write the instruction to read/write to CP15 C13 with
the ThreadID opcode. However on no armv5 implementation will the CP15
C13 have a Thread ID register. The GCC intent seems to be whether the
instruction is encodable rather than check what the CPU supports.
Link: https://github.com/ClangBuiltLinux/linux/issues/1502
Link: https://developer.arm.com/documentation/ddi0301/h/system-control-coprocessor/system-control-processor-registers/c13--thread-and-process-id-registers
Reviewed By: ardb, peter.smith
Differential Revision: https://reviews.llvm.org/D114116
Currently, we permit -mtp=cp15 even for targets that don't implement the
TLS register. When building for ARMv6 or earlier, this means we emit
instructions that will UNDEF at runtime. For Thumb1, passing -mtp=cp15
will trigger an assert in the backend.
So let's add some diagnostics to ensure that -mtp=cp15 is only accepted
for ARMv6T2 or newer.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D113026
Windows on armv7 is as alignment tolerant as Linux.
The alignment considerations in the Windows on ARM ABI are documented
at https://docs.microsoft.com/en-us/cpp/build/overview-of-arm-abi-conventions?view=msvc-160#alignment.
The document doesn't explicitly say in which state the OS configures
the SCTLR.A register (and it's not accessible from user space to
inspect), but in practice, unaligned loads/stores do work and seem
to be as fast as aligned loads and stores. (Unaligned strd also does
seem to work, contrary to Linux, but significantly slower, as they're
handled by the kernel - exactly as the document describes.)
Differential Revision: https://reviews.llvm.org/D109960
Recently a vulnerability issue is found in the implementation of VLLDM
instruction in the Arm Cortex-M33, Cortex-M35P and Cortex-M55. If the
VLLDM instruction is abandoned due to an exception when it is partially
completed, it is possible for subsequent non-secure handler to access
and modify the partial restored register values. This vulnerability is
identified as CVE-2021-35465.
The mitigation sequence varies between v8-m and v8.1-m as follows:
v8-m.main
---------
mrs r5, control
tst r5, #8 /* CONTROL_S.SFPA */
it ne
.inst.w 0xeeb00a40 /* vmovne s0, s0 */
1:
vlldm sp /* Lazy restore of d0-d16 and FPSCR. */
v8.1-m.main
-----------
vscclrm {vpr} /* Clear VPR. */
vlldm sp /* Lazy restore of d0-d16 and FPSCR. */
More details on
developer.arm.com/support/arm-security-updates/vlldm-instruction-security-vulnerability
Differential Revision: https://reviews.llvm.org/D109157
'armv7-pc-win32-macho'
It is incorrect to select the hardware floating point ABI on Mach-O
platforms using the Windows triple if the ABI is "apcs-gnu".
rdar://81810554
Differential Revision: https://reviews.llvm.org/D107939
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 patch contains a couple of minor corrections to my previous
crypto patch:
Since both AArch32 and AArch64 are now correctly setting the aes and
sha2 features individually, it is not necessary to continue to check
the crypto feature when defining feature macros.
In the AArch32 driver, the feature vector is only modified when the
crypto feature is actually in the vector. If crypto is not present,
there is no need to split it and explicitly define crypto/sha2/aes.
Reviewed By: lenary
Differential Revision: https://reviews.llvm.org/D102406
This patch changes the AArch32 crypto instructions (sha2 and aes) to
require the specific sha2 or aes features. These features have
already been implemented and can be controlled through the command
line, but do not have the expected result (i.e. `+noaes` will not
disable aes instructions). The crypto feature retains its existing
meaning of both sha2 and aes.
Several small changes are included due to the knock-on effect this has:
- The AArch32 driver has been modified to ensure sha2/aes is correctly
set based on arch/cpu/fpu selection and feature ordering.
- Crypto extensions are permitted for AArch32 v8-R profile, but not
enabled by default.
- ACLE feature macros have been updated with the fine grained crypto
algorithms. These are also used by AArch64.
- Various tests updated due to the change in feature lists and macros.
Reviewed By: lenary
Differential Revision: https://reviews.llvm.org/D99079
This moves code that sets the architecture name
and Float ABI into two new functions in
ToolChains/Arch/ARM.cpp. Greatly simplifying ComputeLLVMTriple.
Some light refactoring in setArchNameInTriple to
move local variables closer to their first use.
Reviewed By: ostannard
Differential Revision: https://reviews.llvm.org/D98253
This fixes Bugzilla #48894 for Arm, where it
was reported that -Wa,-march was not being handled
by the integrated assembler.
This was previously fixed for -Wa,-mthumb by
parsing the argument in ToolChain::ComputeLLVMTriple
instead of CollectArgsForIntegratedAssembler.
It has to be done in the former because the Triple
is read only by the time we get to the latter.
Previously only mcpu would work via -Wa but only because
"-target-cpu" is it's own option to cc1, which we were
able to modify. Target architecture is part of "-target-triple".
This change applies the same workaround to -march and cleans up
handling of -Wa,-mcpu at the same time. There were some
places where we were not using the last instance of an argument.
The existing -Wa,-mthumb code was doing this correctly,
so I've just added tests to confirm that.
Now the same rules will apply to -Wa,-march/-mcpu as would
if you just passed them to the compiler:
* -Wa/-Xassembler options only apply to assembly files.
* Architecture derived from mcpu beats any march options.
* When there are multiple mcpu or multiple march, the last
one wins.
* If there is a compiler option and an assembler option of
the same type, we prefer the one that fits the input type.
* If there is an applicable mcpu option but it is overruled
by an march, the cpu value is still used for the "-target-cpu"
cc1 option.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D95872
The command line syntax is identical to the -mharden-sls= command line
syntax for AArch64 targets.
Differential Revision: https://reviews.llvm.org/D93221
LLVM assumes that when it creates a call to a C library function it
can use the C calling convention. On ARM the effective calling
convention is determined from the target triple, however using
-mfloat-abi=hard on ARM means that calls to (and definitions of) C
library functions use the arm_aapcs_vfpcc calling convention which can
result in a mismatch.
Fix this by incorporating -mfloat-abi into the target triple, similar
to how -mbig-endian and -march/-mcpu are. This only works for EABI
targets and not Android or iOS, but there the float abi is fixed so
instead give an error.
Fixes PR45524
Differential Revision: https://reviews.llvm.org/D89573
A list of target features is disabled when there is no hardware
floating-point support. This is the case when one of the following
options is passed to clang:
- -mfloat-abi=soft
- -mfpu=none
This option list is missing, however, the extension "+nofp" that can be
specified in -march flags, such as "-march=armv8-a+nofp".
This patch also disables unsupported target features when nofp is passed
to -march.
Differential Revision: https://reviews.llvm.org/D82948
-march=armv8.1-m.main+mve.fp+nomve -mfpu=none should disable FP
registers and instructions moving to/from FP registers.
This patch fixes the case when "+mve" (added to the feature list by
"+mve.fp"), is followed by "-mve" (added by "+nomve").
Differential Revision: https://reviews.llvm.org/D72633
Summary:
- Similar to other targets, instead of passing a toolchain, a driver
argument should be passed into `arm::getARMTargetFeatures`. Aslo, that
routine should honor the specified triple. Refactor
`arm::getARMFloatABI` with 2 separate interfaces. One has the original
parameters and the other uses the driver and the specified triple.
- That fixes an issue when target & features are queried during the
offload compilation, where the specified triple should be checked
instead of a effective triple. A previously failed test is re-enabled.
Subscribers: kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D74020
Summary:
This patch changes the underlying type of the ARM::ArchExtKind
enumeration to uint64_t and adjusts the related code.
The goal of the patch is to prepare the code base for a new
architecture extension.
Reviewers: simon_tatham, eli.friedman, ostannard, dmgreen
Reviewed By: dmgreen
Subscribers: merge_guards_bot, kristof.beyls, hiraditya, cfe-commits, llvm-commits, pbarrio
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D73906
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.
Architecturally, it's allowed to have MVE-I without an FPU, thus
-mfpu=none should not disable MVE-I, or moves to/from FP-registers.
This patch removes `+/-fpregs` from features unconditionally added to
target feature list, depending on FPU and moves the logic to Clang
driver, where the negative form (`-fpregs`) is conditionally added to
the target features list for the cases of `-mfloat-abi=soft`, or
`-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative
form is added by the driver, the positive one is derived from other
features in the backend.
Differential Revision: https://reviews.llvm.org/D71843
Provides support for using r6-r11 as globally scoped
register variables. This requires a -ffixed-rN flag
in order to reserve rN against general allocation.
If for a given GRV declaration the corresponding flag
is not found, or the the register in question is the
target's FP, we fail with a diagnostic.
Differential Revision: https://reviews.llvm.org/D68862
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
Since `-mfloat-abi=soft` is taken to mean turning off all uses of the
FP registers, it should turn off the MVE vector instructions as well
as NEON and scalar FP. But it wasn't doing so.
So the options `-march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft`
would cause the underlying LLVM to //not// support MVE (because it
knows the real target feature relationships and turned off MVE when
the `fpregs` feature was removed), but the clang layer still thought
it //was// supported, and would misleadingly define the feature macro
`__ARM_FEATURE_MVE`.
The ARM driver code already has a long list of feature names to turn
off when `-mfloat-abi=soft` is selected. The fix is to add the missing
entries `mve` and `mve.fp` to that list.
Reviewers: dmgreen
Subscribers: kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69025
llvm-svn: 375001
Summary:
This patch restores the behaviour that -fpu overwrites the
architecture obtained from -march or -mcpu flags, not enforcing to
disable 'crypto' if march=armv7 and mfpu=neon-fp-armv8.
However, it does warn that 'crypto' is ignored when passing
mfpu=crypto-neon-fp-armv8.
Reviewers: peter.smith, labrinea
Reviewed By: peter.smith
Subscribers: nickdesaulniers, kristof.beyls, dmgreen, cfe-commits, krisb
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67608
llvm-svn: 374785
Submittin in behalf of krisb (Kristina Bessonova) <ch.bessonova@gmail.com>
Summary:
'+crypto' means '+aes' and '+sha2' for arch >= ARMv8 when they were
not disabled explicitly. But this is correctly handled only in case of
'-march' option, though the feature may also be specified through
the '-mcpu' or '-mfpu' options. In the following example:
$ clang -mcpu=cortex-a57 -mfpu=crypto-neon-fp-armv8
'aes' and 'sha2' are disabled that is quite unexpected:
$ clang -cc1 -triple armv8--- -target-cpu cortex-a57
<...> -target-feature -sha2 -target-feature -aes -target-feature +crypto
This exposed by https://reviews.llvm.org/D63936 that makes
the 'aes' and 'sha2' features disabled by default.
So, while handling the 'crypto' feature we need to take into account:
- a CPU name, as it provides the information about architecture
(if no '-march' option specified),
- features, specified by the '-mcpu' and '-mfpu' options.
Reviewers: SjoerdMeijer, ostannard, labrinea, dnsampaio
Reviewed By: dnsampaio
Subscribers: ikudrin, javed.absar, kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66018
Author: krisb
llvm-svn: 371597
When processing the command line options march, mcpu and mfpu, we store
the implied target features on a vector. The change D62998 introduced a
temporary vector, where the processed features get accumulated. When
calling DecodeARMFeaturesFromCPU, which sets the default features for
the specified CPU, we certainly don't want to override the features
that have been explicitly specified on the command line. Therefore, the
default features should appear first in the final vector. This problem
became evident once I added the missing (unhandled) target features in
ARM::getExtensionFeatures.
Differential Revision: https://reviews.llvm.org/D63936
llvm-svn: 366027
Removes a vector reference that was added by D62998, since the
preexisting function parameter is sufficient.
Differential Revision: https://reviews.llvm.org/D64044
llvm-svn: 364895
Change D60691 caused some knock-on failures that weren't caught by the
existing tests. Firstly, selecting a CPU that should have had a
restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs
and no double precision) could give the unrestricted version, because
`ARM::getFPUFeatures` returned a list of features including subtracted
ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw
away all the ones that didn't start with `+`. Secondly, the
preprocessor macros didn't reliably match the actual compilation
settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as
if hardware FP was available, because the list of features on the cc1
command line would include things like `+vfp4`,`-vfp4d16` and clang
didn't realise that one of those cancelled out the other.
I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so
that it returns a list that enables every FP-related feature
compatible with the selected FPU and disables every feature not
compatible, which is more verbose but means clang doesn't have to
understand the dependency relationships between the backend features.
Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all
the various forms of the FP feature names, so that it won't miss cases
where it should have set `HW_FP` to feed into feature test macros.
That in turn caused an ordering problem when handling `-mcpu=foo+bar`
together with `-mfpu=something_that_turns_off_bar`. To fix that, I've
arranged that the `+bar` suffixes on the end of `-mcpu` and `-march`
cause feature names to be put into a separate vector which is
concatenated after the output of `getFPUFeatures`.
Another side effect of all this is to fix a bug where `clang -target
armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even
though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was
because `HW_FP` was being set to a value including only the `FPARMV8`
bit, but that feature test macro was testing only the `VFP4FPU` bit.
Now `HW_FP` ends up with all the bits set, so it gives the right
answer.
Changes to tests included in this patch:
* `arm-target-features.c`: I had to change basically all the expected
results. (The Cortex-M4 test in there should function as a
regression test for the accidental double-precision bug.)
* `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG`
everywhere so that those tests are no longer sensitive to the order
of cc1 feature options on the command line.
* `arm-acle-6.5.c`: been updated to expect the right answer to that
FMA test.
* `Preprocessor/arm-target-features.c`: added a regression test for
the `mfpu=softvfp` issue.
Reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, JamesNagurne
Reviewed By: ostannard
Subscribers: srhines, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D62998
llvm-svn: 362791
Now, when clang processes an argument of the form "-march=foo+x+y+z",
then instead of calling getArchExtFeature() for each of the extension
names "x", "y", "z" and appending the returned string to its list of
low-level subtarget features, it will call appendArchExtFeatures()
which does the appending itself.
The difference is that appendArchExtFeatures can add _more_ than one
low-level feature name to the output feature list if it has to, and
also, it gets told some information about what base architecture and
CPU the extension is going to go with, which means that "+fp" can now
mean something different for different CPUs. Namely, "+fp" now selects
whatever the _default_ FPU is for the selected CPU and/or
architecture, as defined in the ARM_ARCH or ARM_CPU_NAME macros in
ARMTargetParser.def.
On the clang side, I adjust DecodeARMFeatures to call the new
appendArchExtFeatures function in place of getArchExtFeature. This
means DecodeARMFeatures needs to be passed a CPU name and an ArchKind,
which meant changing its call sites to make those available, and also
sawing getLLVMArchSuffixForARM in half so that you can get an ArchKind
enum value out of it instead of a string.
Also, I add support here for the extension name "+fp.dp", which will
automatically look through the FPU list for something that looks just
like the default FPU except for also supporting double precision.
Differential Revision: https://reviews.llvm.org/D60697
llvm-svn: 362601
The recent change D60691 introduced a bug in clang when handling
option combinations such as `-mcpu=cortex-m4 -mfpu=none`. Those
options together should select Cortex-M4 but disable all use of
hardware FP, but in fact, now hardware FP instructions can still be
generated in that mode.
The reason is because the handling of FPUVersion::NONE disables all
the same feature names it used to, of which the base one is `vfp2`.
But now there are further features below that, like `vfp2d16fp` and
(following D60694) `fpregs`, which also need to be turned off to
disable hardware FP completely.
Added a tiny test which double-checks that compiling a simple FP
function doesn't access the FP registers.
Reviewers: SjoerdMeijer, dmgreen
Reviewed By: dmgreen
Subscribers: lebedev.ri, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D62729
llvm-svn: 362380
Fangrui Song