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

[Craig Topper via llvm-commits]

topperc wrote:

We have a history of changing the names of tune features. I think exposing these in a -mtune option creates an expectation of backwards compatibility and stability that `-Xclang -target-feature -Xclang <feature>` doesn't necessarily have.

Some of these tune features are poorly named for exposing to users. Especially "no-default-unroll". Would we be allowed to change the implementation of "no-default-unroll" once its exposed?

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.

How do users discover the supported options?

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.

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