================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
