[llvm] [RISCV] Introduce a new tune feature string syntax and its parser (PR #168160)

[Sam Elliott via llvm-commits]

lenary wrote:

I agree that we need to be careful about what we expose, as we end up having to support it long term. `-menable-experimental-tuning-features` or similar is good on that front.

On the other hand, I'm not sure we need the complexity of restricting specific features to specific CPUs. For two reasons:
- There are some tuning features which are orthogonal to the CPU Scheduling Model - SFB for instance. Maybe this is the only group of these though? I'm not sure. Users may still want to use them even if their scheduling model doesn't have accurate latency/occupancy modelling for these instructions, as they can still help performance in that circumstance.
- The parser has to ignore unknown tuning features already for compatibility with other toolchains, so i don't think it's the end of the world if you give `generic:no-sifive-whatever`, where `sifive-whatever` is for a specific sifive scheduling model. This is effectively the same as `generic`.

I don't fully know the answers here, but we have been clear so far that:
- the available features will not necessarily match between toolchains (though we hope a subset of them will match)
- similarly, toolchains may not be able to implement tuning features supported by other toolchains, because the architectures of the compilers differ (but we hope a subset of them will match)
- unknown features should not error
- none of these features should affect whether the generated code is correct



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