[clang] [llvm] [RISCV] Add support for getHostCPUFeatures using hwprobe (PR #94352)

Philip Reames via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 1 08:01:18 PDT 2024


================
@@ -290,8 +290,24 @@ StringRef riscv::getRISCVArch(const llvm::opt::ArgList &Args,
   // 2. Get march (isa string) based on `-mcpu=`
   if (const Arg *A = Args.getLastArg(options::OPT_mcpu_EQ)) {
     StringRef CPU = A->getValue();
-    if (CPU == "native")
+    if (CPU == "native") {
       CPU = llvm::sys::getHostCPUName();
+      // If the target cpu is unrecognized, use target features.
+      if (CPU.empty() || CPU.starts_with("generic")) {
+        llvm::StringMap<bool> HostFeatures;
+        if (llvm::sys::getHostCPUFeatures(HostFeatures)) {
+          std::vector<std::string> Features;
+          for (auto &F : HostFeatures)
+            Features.push_back(
+                Args.MakeArgString((F.second ? "+" : "-") + F.first()));
+
+          auto ParseResult = llvm::RISCVISAInfo::parseFeatures(
+              Triple.isRISCV32() ? 32 : 64, Features);
+          if (ParseResult)
+            return (*ParseResult)->toString();
----------------
preames wrote:

Good catch.  Returning std::string for now appears to be the path of least resistance.

Glancing at the callers, I note that more than half immediately call parseArchString.  We could invert the API here, and return the parsed ISAInfo, and then convert that back into string form on demand.  I didn't see any cases where we wanted the string form of an invalid architecture combination - that would be the case which might prevent the API inversion.  

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


More information about the llvm-commits mailing list