kito-cheng added a comment. There is several issue around the default extension version stuffs.
- Should we add `-misa-spec=` option to Clang/LLVM? - Behavior for `zifencei` and `zicsr` with `i` 2.0? - How to encode the extension version in LLVM? by attribute or module flags? --- Should we add `-misa-spec=` option to Clang/LLVM? ------------------------------------------------- Here is a long discussion[1] at 2019, at that moment I think we all agree -misa-spec is a good solution, However it's kind of awkward for this scheme is ISA spec changing the version scheme again after `20191213` release, it's become NO formal release for long time, just bunch of draft release. That's means NO `-misa-spec` version can cover vector, crypto and bit manipulation. So we might consider different scheme on controlling default version, or change the semantic of `-misa-spec` to make it no longer just reference version of RISC-V ISA manual, maybe we could reference RISC-V profile[2], but the spec still under discussion. For GNU toolchain land, `-misa-spec=` already implemented in GNU toolchain about ~ 2yrs, so I prefer change the semantic to reference version other than version of RISC-V ISA manual rather than adding new command line option to control that. [1] https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aZhMG7NIVTk/m/PTZEaTWiAwAJ [2] https://github.com/riscv/riscv-profiles --- Behavior for `zifencei` and `zicsr` with `i` 2.0? ------------------------------------------------- I would suggest still accept `i` 2.0 with `zifencei` and `zicsr` for compatibility, but NO effect and NO ELF attribute for those two extensions if `I` is `2.0`, however I don't have strong opinion on this issue. --- How to encode the extension version in LLVM? by attribute or module flags? -------------------------------------------------------------------------- It's kind of LLVM specific implementation issue, RISC-V LLVM use target attribute to enable/disable specific extension, but we didn't encode version info in target attribute or module flags yet, there is not too much problem on clang side during parsing arch string, but that cause some problem on ELF attribute emission, `+a` means `2.0` or `2.1`? `+f` means `2.0`, `2.1` or `2.2`? and what the version of `i`? `i` has major change between `2.0` and `2.1`, so we might consider adding new target attribute (e.g `+i2p1`?) to identify the version of `i`. But `f` and `d` is clarification on the NaN behavior, which is related minor for toolchain, so adding new target attribute to that is kind of ... weird? `f`/`d` 2.0 FMIN.S and FMAX.S write, respectively, the smaller or larger of rs1 and rs2 to rd. `f`/`d` 2.2 Floating-point minimum-number and maximum-number instructions FMIN.S and FMAX.S write, respectively, the smaller or larger of rs1 and rs2 to rd. For the purposes of these instructions only, the value −0.0 is considered to be less than the value +0.0. If both inputs are NaNs, the result is the canonical NaN. If only one operand is a NaN, the result is the non-NaN operand. Signaling NaN inputs set the invalid operation exception flag, even when the result is not NaN. Anyway, I think here is two possible solution, but I didn't have strong opinion here: - Add new target attribute for each version. - Encode whole arch string with explicit version into module flag. Note: Ext. versions in RISC-V ISA spec 20191213: `I` 2.1, `M` 2.0, `A` 2.1, `F` 2.2, `D` 2.2, `C` 2.0, `E` 1.9, `Zicsr` 2.0, `Zifencei` 2.1 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D113237/new/ https://reviews.llvm.org/D113237 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
