[llvm] [clang] [RISCV] Update TargetAttr target-cpu override rule (PR #75804)
Michael Maitland via llvm-commits
llvm-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 llvm-commits
mailing list