[llvm] [RISCV] Introduce a new tune feature string syntax and its parser (PR #168160)
Min-Yih Hsu via llvm-commits
llvm-commits at lists.llvm.org
Tue Dec 2 14:46:11 PST 2025
mshockwave wrote:
> Have a discussion with @topperc on this comment: [riscv-non-isa/riscv-toolchain-conventions#122 (comment)](https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/122#discussion_r2558108285) That is, whether some subtarget features are just not suitable for using as a tuning directive here. Take the DLEN factor of 2 as an example, right now some scheduling models do factor DLEN into their latency or occupancy numbers. But for those models, DLEN is effectively hard-coded. Meaning latency & occupancy could not be adjusted with arbitrary DLEN values. So if we say something like `-mtune=sifive-x280:no-dlen-factor-2` there will be no effect on the scheduling model. The only other place `dlen-factor-2` is used is the TTI cost model for calculating LMUL cost . But since we cannot adjust the scheduling model, adjusting _only_ the TTI cost model through `-mtune=sifive-x280:no-dlen-factor-2` would cause mismatching between the LLVM IR instruction cost and the machine instruction schedule. In other words, scheduling model and TTI cost model are locked together in this case, we either adjust both of them or we don't. And since we cannot adjust both due to the reason explained earlier, it doesn't make sense to apply `dlen-factor-2/no-dlen-factor-2` in the new `-mtune` string.
Another thing that came out this discussion, and related to https://github.com/llvm/llvm-project/pull/168160#discussion_r2548737453 as well, is that we probably want to have a curated list of accepted tuning directive for each CPU. For example, right now `single-element-vec-fp64` is only used by SiFive7's model, so for other CPUs we can say something like "single-element-vec-fp64 has no effect on the scheduling model" (or the other way around, only states the accepted tuning directives).
https://github.com/llvm/llvm-project/pull/168160
More information about the llvm-commits
mailing list