| commit | 8fa0f0efce5fb81eb422e6d7eec74c66dafef4a3 | [log] [tgz] |
|---|---|---|
| author | Martin Storsjö <martin@martin.st> | Thu Jan 16 22:49:09 2025 +0200 |
| committer | GitHub <noreply@github.com> | Thu Jan 16 22:49:09 2025 +0200 |
| tree | 44e5cff410efd3fbc30a2d22af5c00d982b1fd58 | |
| parent | 94609aee73d7123bc9afe002a4987d06eba9f452 [diff] |
[clang] [ARM] Explicitly enable NEON for Windows/Darwin targets (#122095)
Upstream LLVM implicitly enables NEON for any ARMv7 target.
Many platform ABIs with an ARMv7 baseline also include NEON in that,
this is the case on e.g. Windows and iOS. On Linux, however, things are
not quite as clearly defined. Some distributions target an ARMv7
baseline without NEON available (this is the case for e.g. Debian/Ubuntu
for the "armhf" architecture).
To achieve this, Debian/Ubuntu patch LLVM downstream to make ARMv7 only
implicitly enable VPFv3-D16, not NEON - see [1].
That patch has the (unintended) effect that NEON no longer is available
by default for Windows/ARMv7 and iOS/ARMv7.
In practice, when compiling C for Windows/ARMv7 with Debian patched
Clang, NEON actually still is available, but not when compiling assembly
files. This is due to ARM::getARMCPUForArch (in
llvm/lib/TargetParser/ARMTargetParser.cpp) returning "cortex-a9" for
Windows. This difference, between C and assembly, is due to how
getARMTargetCPU is called in getARMTargetFeatures (in
clang/lib/Driver/ToolChains/Arch/ARM.cpp) to get defaults, only when
ForAS is not set - see [2].
There is an existing case in getARMTargetFeatures, for Android, which
explicitly enables NEON when targeting ARM >= v7. As Windows and iOS
have NEON as part of their ABI baseline just like Android does these
days (see [3] for where this default was added for Android), add the
implicit default in a similar way.
However, first do the general lookup of getARMTargetCPU (unless ForAS);
this makes sure that we get the same default CPU as before ("cortex-a9"
for Windows and "swift" for the "armv7s" architecture on Darwin).
[1] https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/blob/19/debian/patches/clang-arm-default-vfp3-on-armv7a.patch?ref_type=heads
[2] https://github.com/llvm/llvm-project/commit/b8baa2a9132498ea286dbb0d03f005760ecc6fdb
[3] https://github.com/llvm/llvm-project/commit/d0fbef9c753a78aa20d5a462b682bfaf83cc6e6e
Welcome to the LLVM project!
This repository contains the source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.
The LLVM project has multiple components. The core of the project is itself called “LLVM”. This contains all of the tools, libraries, and header files needed to process intermediate representations and convert them into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer.
C-like languages use the Clang frontend. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.
Other components include: the libc++ C++ standard library, the LLD linker, and more.
Consult the Getting Started with LLVM page for information on building and running LLVM.
For information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.
Join the LLVM Discourse forums, Discord chat, LLVM Office Hours or Regular sync-ups.
The LLVM project has adopted a code of conduct for participants to all modes of communication within the project.