================
@@ -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()) &&
----------------
DavidSpickett wrote:
So the logic for the "generic" check is that `clang -target windows` will be
using cpu generic, fine. If you were specifying the CPU of a real target
device, then presumably that would have Neon and Clang would know that anyway.
Only if you're doing something strange with a CPU that's never had iOS or
Windows run on it, only then does this code not apply. But given that it's a
strange use case, it's best to leave it alone and just take the user's intent
literally.
Correct?
Also I note that Android does not do this generic CPU check. I don't think
making it do that should be part of this PR, and so, while I think this code is
spaghetti, I wouldn't try to merge them here. Probably wouldn't break anything,
but probably isn't zero chance.
https://github.com/llvm/llvm-project/pull/122095
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
