================
@@ -52,6 +52,22 @@ std::string aarch64::getAArch64TargetCPU(const ArgList &Args,
return "apple-m1";
}
+ if (Triple.getOS() == llvm::Triple::IOS) {
+ assert(!Triple.isSimulatorEnvironment() && "iossim should be mac-like");
+ // iOS 26 only runs on apple-a12 and later CPUs.
+ if (!Triple.isOSVersionLT(26))
+ return "apple-a12";
+ }
----------------
ahmedbougacha wrote:
Ah right, I think of those as a remnant of early LTO support, a default
fallback for cases where the frontend doesn't set up the target IR attributes.
The last addition was arm64e/a12, when we still had unattributed functions, in
obscure corners of clang IRGen that synthesize thunks and wrappers. I'd expect
those to be thoroughly eliminated now, after the waves of ptrauth attribute
variations that will break if missing, and can't rely on this sort of late
fallback.
So I'd say we could probably try to remove the LTO logic altogether, at the
risk of breaking some library users without a clang-equivalent driver.
There's a case to be made this logic should be an llvm default backing a driver
override, which would help other users. I don't think that's a bad idea, and
it seems it'd belong in TargetParser? But overall I think it's just another on
the long list of low-level choices that clang has to do and are hard to
separate; using clang seems unavoidable (also see Jordan and John's old llvm
devmtg talk "Skip the FFI" ;)
https://github.com/llvm/llvm-project/pull/152235
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
