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

[Min-Yih Hsu via llvm-commits]

mshockwave wrote:

> As noted many of our tune features are directly related to scheduler implementation. Changing them without changing the CPU will yield some result, but maybe not the expected one. Though I'm not sure anyone could really know what to expect.
> 
> Mixing these features with different CPUs creates a huge configuration space that is not really tested. Making it part of -mtune makes it feel more officially supported than `-Xclang -target-feature -Xclang <feature>`, but its not really.
> 
> I think we need to think carefully about naming, long term stability, documentation of the features, and compatibility with gcc before we expose a batch of our existing tuning features.

I think these issues could be boiled down into three things:
  - Limiting the scope of the supported tuning directives for each CPU
  - Naming (e.g. the default unroll example you pointed out)
  - Documentation

I think the naming (and to some extent, its documentation) would take some times, especially taking into the fact that we have to work with GCC on this matter as well. So personally I would prefer that to be an incremental efforts. What we can do now, in order to keep the ball rolling, is building the technical infrastructure, which this PR is part of. And that brings us to the first bullet item, which limits the list of _acceptable_ tuning features for each CPU.

Probably the easiest and most straightforward way is to just let each CPU to decide which tuning features are allowed. To that end I think we can do something like:
```
def SIFIVE_X280 : RISCVProcessorModel<"sifive-x280", SiFive7Model,
                                      [/*existing ISA features*/], [/*existing tune features*/]>,
                  RISCVConfigurableTuneFeatures<[TuneHasSingleElementVecFP64]>;
```
The `RISCVConfigurableTuneFeatures` will be a new TableGen class to specify the list of acceptable tune features for its associated CPU. In the prospective `-mtune` string, a processor can _only_ used tuning directives from this list (i.e. it's opt-in). For example, in this case `sifive-x280` can only use `single-element-vec-fp64` in `-mtune=sifive-x280:...`.

Please let me know what you think.

Fore each tuning feature, I'm also thinking whether the processor could choose to allow only the positive or negative directive. For example, it makes little sense to enable short forward branch against scheduling model that doesn't have the corresponding latency & occupancy, but it would be useful for user to _disable_ short forward branch. However, for scheduling models without SFB scheduling data, they could just ban using the entire SFB tuning feature; for scheduling model that already has SFB, enabling the SFB subtarget feature again won't make a difference. So I don't see benefits of having a finer granularity here for now.

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