[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

0 files changed, 0 insertions, 0 deletions