riscv-non-isa/riscv-toolchain-conventions

Unify interface to query supported option for extension

kito-cheng opened this issue · 11 comments

kito-cheng commented

We've -mtune=? and -mcpu=? in clang to query supported option for those options, but we are lacking a interface to query supported extension for RISC-V, the only way is checking the release note or read the source code, which is not user friendly way.

So I think we might need to add something like -march=? to print out all supported extension and supported version, and would be great to having consistent interface and output, so that user could have easier to write some script to parse.

-march=?

Supported extension : Version
i : 2.0
m : 2.0
f : 2.0, 2.1
...
zvfh (experimental) : 0.1     // Should we show `(experimental)`?, version less than 1.0 implied experimental support
cmuellner commented

The toolchain conventions describe the expected behavior of RISC-V toolchains (or their components).
I would not expect that all toolchain components can list their supported march substrings.

So if we streamline an interface like this, we should probably put it in a "preferred, but not widely available CLI flags" section.

kito-cheng commented

So if we streamline an interface like this, we should probably put it in a "preferred, but not widely available CLI flags" section.

Yeah, sounds good, my goal is support that at least on clang, gcc and GNU as.

asb commented

In the RISC-V LLVM meeting @compnerd raised the point that clang has a way of listing supported targets already, and an alternative might be to just modify that to list the supported extensions. There was also a concern that -march is currently documented to be an ISA string. On the other hand, it feels to me like changing behaviour on an invalid ISA string (in this case, ?) shouldn't be too problematic.

cmuellner commented

Regarding the comment from @compnerd: Is clang -print-targets meant, so the alternative would be clang -target=riscv64 -print-marchs?

What about other flags like -mabi and -mcmodel? Shouldn't the way to query their accepted strings be streamlined as well?

compnerd commented

I think that we could just list the available extensions in -print-targets. That avoids another flag and when you check whether RISCV is available you immediately see the extensions available as well, improving discoverability.

-mcmodel for RISCV is limited to medlow, medany.
-mabi for RISCV is limited to ilp32, ilp32f, ilp32d, lp64, lp64f, and lp64d.

Neither of these require querying, and the possible inputs are well documented at https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Options.html#RISC-V-Options. The difference with -march is that you do not know what extensions are supported by the compiler, and thus requires an additional listing.

cmuellner commented

The list of accepted values for both mcmodel and mabi can be extended in the future. E.g. a new large code model would add a value for mcmodel and a user might want to find out if a compiler implements that.

asb commented

And Clang/LLVM doesn't support ILP32E right now, but we expect it will in the future.

compnerd commented

Sure, it can be extended in the future. However, given that the premise for the new support was "we do not know what value values are" which was clarified to "we do not know what the compiler supports without checking", I think that just listing them in the -print-targets makes the most sense.

TommyMurphyTM1234 commented

-mabi for RISCV is limited to ilp32, ilp32f, ilp32d, lp64, lp64f, and lp64d.

And ilp32e?

kito-cheng commented

I would prefer adding -march=? rather than -print-targets or -print-supported-archs due to following reasons:

  • -print-targets option is used to listing all supported target, and it automatically generated by all registered targets, adding new info might disturb some script which try to parsing that, and hard to determine we support print RISC-V extension info or not - introducing new option or -march=? could just determine by the output rater than parse the output.

  • -print-supported-archs is good option, -mcpu=? and -mtune=? is actually alias of -print-supported-cpus in clang, so adding -print-supported-archs seems make sense, but the option is target dependent, so I would strongly the option should prefixed with -m, especially the option is not only need to adding in clang, but also in GNU toolchain.

  • Consider -mabi and -mcmodel, accept =? for every option could be more consistent.

asb commented

I've raised this topic in the Clang Discourse to see if there are any strong views one way or another for adding more -foo=? style options to Clang.