[clang] [clang] [ARM] Explicitly enable NEON for Windows/Darwin targets (PR #122095)

[Martin Storsjö via cfe-commits]

================
@@ -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:

Hi @anemet, sorry about this! While I did test some combinatons with `armv7s` (as exposed by other testcases), I clearly missed this case.

I tried poking around for different ways of fixing this, but they all more or less amount to the fix as is currently being done in #130623, to remove the `ForAS` check here. (I also felt that that condition was problematic here, but I was afraid that changing that would be a bigger policy change.)

What do you (and @davemgreen, @DavidSpickett an @Stylie777) think here, what's the best course of action for the current 20.x release branch? Should we split out the change to remove the `ForAS` condition from the rest of the changes in #130623, making that a smaller separate step which can be backported?

https://github.com/llvm/llvm-project/pull/122095