[llvm] [clang] [RISCV] Update TargetAttr target-cpu override rule (PR #75804)

Michael Maitland via cfe-commits cfe-commits at lists.llvm.org
Wed Jan 17 15:48:37 PST 2024


================
@@ -482,5 +482,35 @@ ParsedTargetAttr RISCVTargetInfo::parseTargetAttr(StringRef Features) const {
       Ret.Tune = AttrString;
     }
   }
+
+  StringRef MCPU = this->getTargetOpts().CPU;
+  StringRef MTune = this->getTargetOpts().TuneCPU;
+
+  // attr-cpu override march only if arch isn't present.
+  if (FoundArch) {
+    // If tune-cpu infer from CPU, then try to keep it.
+    // Otherwise, just use current tune option.
+    if (Ret.Tune.empty() && MTune.empty()) {
+      if (!Ret.CPU.empty())
+        Ret.Tune = Ret.CPU; // Keep attr-cpu in tune-cpu
+      else if (!MCPU.empty())
+        Ret.Tune = MCPU; // Keep mcpu in tune-cpu
+    }
+
+    // Reassign mcpu due to attr-arch=<Adding-Extension> need
+    // target-feature from mcpu/march.
+    // Use attr-cpu will affect target-feature.
+    Ret.CPU = MCPU;
+
+    // arch=<full-arch-string> need keep target feature clean,
+    // use the baseline cpu.
+    if (llvm::find(Ret.Features, "__RISCV_TargetAttrNeedOverride") !=
+        Ret.Features.end())
+      Ret.CPU =
----------------
michaelmaitland wrote:

It looks like `RISCVProcessorModel` takes a name `n` which I think corresponds to the mcpu name, and a `SchedMachineModel m` which I thought was the SchedModel. But I also see that `RISCVTuneProcessorModel` seems to tie the SchedModel to the Tune. So maybe the answer is that it can come from both?



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


More information about the cfe-commits mailing list