Gentoo is planning to introduce a `*t64` suffix for triples that will be
used by 32-bit platforms that use 64-bit `time_t`. Add support for
parsing and accepting these triples, and while at it make clang
automatically enable the necessary glibc feature macros when this suffix
is used.
An open question is whether we can backport this to LLVM 19.x. After
all, adding new triplets to Triple sounds like an ABI change — though I
suppose we can minimize the risk of breaking something if we move new
enum values to the very end.
Previously this took a reference to a map and returned a bool to say
whether it succeeded. We can return a StringMap instead, as all callers
but 1 simply iterated the map if the bool was true, and passed in empty
maps as the starting point.
lldb's lit-cpuid did specifically check whether the call failed, but due
to the way the x86 routines work this works out the same as checking if
the returned map is empty.
When using the -mframe-chain=aapcs or -mframe-chain=aapcs-leaf options,
we cannot use r11 as an allocatable register, even if
-fomit-frame-pointer is also used. This is so that r11 will always point
to a valid frame record, even if we don't create one in every function.
ARM's Clang and GCC embedded compilers default to allowing unaligned
access for ARMv7+. This patch changes the Clang driver default to match.
Users can opt out with `-mno-unaligned-access`.
Fixes#59560
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
When the FPU was selected with "+(no)fp(.dp)" extensions in "-march" or
"-mcpu" options, the FPU used for multilib selection was still the
default one for given architecture or CPU.
When generating armv6-m (Thumb1) Position Independent (PI) code
there are currently some code sequences that are not compatible
with eXecute-Only (XO) code.
For example, this simple code sequence when compiler for XO & PI:
extern int x;
int fn() { return x; }
is a problem as the address of x is currently loaded by:
ldr r0, .L0
:
:
.L0:
.long x
which is not XO compiant as this involves reading the value at
.L0 which is in the code section. Generating correct code is
currently hindered by lack of suitable relocations.
Disallow the generation of armv6-m PI code together with XO code
until they can be made to work together.
Differential Revision: https://reviews.llvm.org/D157620
This patch moves the overall lower-bound arch restriction for Arm XO sections
from v8m to v6m. Actual implementation of code-gen for v6m will follow in
follow-up patches, which will include an implementation of relocations needed to
support this.
Reviewed By: simonwallis2, MaskRay
Differential Revision: https://reviews.llvm.org/D149444
When linking a big-endian image for Arm, clang has
to select between BE8 and BE32 formats. The default
is dependent on the selected target architecture.
For ARMv6 and later architectures the default is
BE8, for older architectures the default is BE32.
For BE8 and BE32, compiler outputs a big endian ELF
relocatable object file with the instructions and
data both big endian. The difference is that at
link time, for BE8 a linker must endian reverse
the instructions to little endian. For BE8, the
clang has to pass --be8 to the linker for Arm.
At the moment clang is not passing the --be8 flag
to linker for the baremetal target architectures
above ArmV6 for Arm. This patch passes through --be8
and -BE or EL to the linker, taking into account the
target and the -mbig-endian and -mlittle-endian flag.
Also there are few more changes in the baremetal
driver so that the code can cope with AArch64 being
big-endian as well.
Reviewed By: michaelplatings, MaskRay
Differential Revision: https://reviews.llvm.org/D154786
Previously, Clang Driver reported a warning when assembler input was assembled
with the -mabi= option. D152856 added TargetSpecific to -mabi= option and
reported an error for such a case. This change restores the previous behavior by
reporting a warning.
GCC translates -mabi={apcs-gnu,atpcs} to gas -meabi=gnu and other -mabi= values
to -meabi=5. We don't support setting e_flags to any value other than
EF_ARM_EABI_VER5.
Close https://github.com/ClangBuiltLinux/linux/issues/1878
Reviewed By: michaelplatings
Differential Revision: https://reviews.llvm.org/D153691
AArch64 has five system registers intended to be useful as thread
pointers: one for each exception level which is RW at that level and
inaccessible to lower ones, and the special TPIDRRO_EL0 which is
readable but not writable at EL0. AArch32 has three, corresponding to
the AArch64 ones that aren't specific to EL2 or EL3.
Currently clang supports only a subset of these registers, and not
even a consistent subset between AArch64 and AArch32:
- For AArch64, clang permits you to choose between the four TPIDR_ELn
thread registers, but not the fifth one, TPIDRRO_EL0.
- In AArch32, on the other hand, the //only// thread register you can
choose (apart from 'none, use a function call') is TPIDRURO, which
corresponds to (the bottom 32 bits of) AArch64's TPIDRRO_EL0.
So there is no thread register that you can currently use in both
targets!
For custom and bare-metal purposes, users might very reasonably want
to use any of these thread registers. There's no reason they shouldn't
all be supported as options, even if the default choices follow
existing practice on typical operating systems.
This commit extends the range of values acceptable to the `-mtp=`
clang option, so that you can specify any of these registers by (the
lower-case version of) their official names in the ArmARM:
- For AArch64: tpidr_el0, tpidrro_el0, tpidr_el1, tpidr_el2, tpidr_el3
- For AArch32: tpidrurw, tpidruro, tpidrprw
All existing values of the option are still supported and behave the
same as before. Defaults are also unchanged. No command line that
worked already should change behaviour as a result of this.
The new values for the `-mtp=` option have been agreed with Arm's gcc
developers (although I don't know whether they plan to implement them
in the near future).
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D152433
The default location for multilib.yaml is lib/clang-runtimes, without
any target-specific suffix. This will allow multilibs for different
architectures to share a common include directory.
To avoid breaking the arm-execute-only.c CHECK-NO-EXECUTE-ONLY-ASM
test, add a ForMultilib argument to getARMTargetFeatures.
Since the presence of multilib.yaml can change the exact location of a
library, relax the baremetal.cpp test.
Differential Revision: https://reviews.llvm.org/D142986
This option causes the flags used for selecting multilibs to be printed.
This is an experimental feature that is documented in detail in D143587.
Differential Revision: https://reviews.llvm.org/D142933
Mixing -mfloat-abi=hard with a CPU that doesn't have floating point
registers is an error in GCC:
cc1: error: '-mfloat-abi=hard': selected processor lacks an FPU
Since there is code in the wild (including in clang tests) that relies
on Clang's current behaviour, emit a warning instead of an error.
Unlike the GCC error, the new warning refers to floating point
registers instead of an FPU. This is because -mfloat-abi=hard and
-march=armv8.1-m.main+mve+nofp are compatible - in that case floating
point registers are required, but an FPU is not required.
My initial thought was to use the floating point ABI calculated by
arm::getARMFloatABI() but in invalid cases which error for other
reasons the ABI is miscalculated and the warning would cause confusion.
Therefore only warn if the user specifies the float ABI explicitly.
Fixes part of https://github.com/llvm/llvm-project/issues/55755
Differential Revision: https://reviews.llvm.org/D150902
Mixing -mfloat-abi=hard with a CPU that doesn't have floating point
registers is an error in GCC:
cc1: error: '-mfloat-abi=hard': selected processor lacks an FPU
Since there is code in the wild (including in clang tests) that relies
on Clang's current behaviour, emit a warning instead of an error.
Unlike the GCC error, the new warning refers to floating point
registers instead of an FPU. This is because -mfloat-abi=hard and
-march=armv8.1-m.main+mve+nofp are compatible - in that case floating
point registers are required, but an FPU is not required.
My initial thought was to use the floating point ABI calculated by
arm::getARMFloatABI() but in invalid cases which error for other
reasons the ABI is miscalculated and the warning would cause confusion.
Therefore only warn if the user specifies the float ABI explicitly.
Fixes part of https://github.com/llvm/llvm-project/issues/55755
Differential Revision: https://reviews.llvm.org/D150902
Add a clang part of OpenHarmony target
Related LLVM part: D138202
~~~
Huawei RRI, OS Lab
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D145227
This change had tests that break whenever LLVM_ENABLE_LINKER_BUILD_ID is
set, as is the case in the Fuchsia target.
This reverts commits:
f81317a54586dbcef0c14cf512a0770e8ecaab3d
72474afa27570a0a1307f3260f0187b703aa6d84
Add a clang part of OpenHarmony target
Related LLVM part: D138202
~~~
Huawei RRI, OS Lab
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D145227
The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC warning about the fact it is deprecated, because it is used
in `isl` from where it is included by Polly.
This is very backend specific so either belongs in Toolchains/ARM or in
ARMTargetParser. Since it is used in lldb, ARMTargetParser made more sense.
This is part of an effort to move information about ARM/AArch64 architecture
versions, extensions and CPUs into their respective TargetParsers.
Differential Revision: https://reviews.llvm.org/D137564
For `-foo=bar`, getSpelling return `-foo=` which is exactly what we need from
the diagnostic. Drop `-` from the err_drv_unsupported_option_argument template.
This change makes `--` long option diagnostics more convenient.
Reviewed By: lenary
Differential Revision: https://reviews.llvm.org/D137659
This compensates for 8f0c901c1a172313a32bc06a1fcface76cd1220f 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
This reverts commit 7625e01d661644a560884057755d48a0da8b77b4 and
dependent cbcce82ef6b512d97e92a319a75a03e997c844e1.
Commit 7625e01d661644a560884057755d48a0da8b77b4 causes some new codegen test
failures under asan, e.g., CodeGen/ARM/execute-only.ll:
https://lab.llvm.org/buildbot/#/builders/5/builds/24659/steps/15/logs/stdio.
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
