[clang] [clang] [ARM] Explicitly enable NEON for Windows/Darwin targets (PR #122095)
Martin Storsjö via cfe-commits
cfe-commits at lists.llvm.org
Thu Jan 16 03:17:12 PST 2025
================
@@ -659,13 +659,21 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver &D,
CPUArgFPUKind != llvm::ARM::FK_INVALID ? CPUArgFPUKind : ArchArgFPUKind;
(void)llvm::ARM::getFPUFeatures(FPUKind, Features);
} else {
+ bool Generic = true;
if (!ForAS) {
std::string CPU = arm::getARMTargetCPU(CPUName, ArchName, Triple);
+ if (CPU != "generic")
+ Generic = false;
llvm::ARM::ArchKind ArchKind =
arm::getLLVMArchKindForARM(CPU, ArchName, Triple);
FPUKind = llvm::ARM::getDefaultFPU(CPU, ArchKind);
(void)llvm::ARM::getFPUFeatures(FPUKind, Features);
}
+ if (Generic && (Triple.isOSWindows() || Triple.isOSDarwin()) &&
----------------
mstorsjo wrote:
Almost; `clang -target armv7-apple-darwin` will return `"generic"` above, and we'll need to add in NEON explicitly to it. However `armv7-windows` will get a default CPU of `cortex-a9` which has NEON (and more). This case isn't necessarily something we need to preserve much about, but a case of `armv7s-apple-darwin` does get hit by one of the testcases, and `armv7s` does also get a specific CPU (`swift`) which also has got NEON and FP16 - and the distinction from that is picked up by an existing testcase.
So only for the cases where `arm::getARMTargetCPU()` doesn't return a specific CPU for this arch/OS target combo, we hit the "generic" case, where we want to add in reasonable defaults.
Yes, the fact that Android has its own check further above, means that it doesn't hit the `arm::getARMTargetCPU()` case, and doesn't pick up defaults from there (where it can add more core specific things like FP16 etc) - and indeed, I'm trying to avoid changing anything wrt that, even if it probably could work with this new codepath as well.
https://github.com/llvm/llvm-project/pull/122095
More information about the cfe-commits
mailing list