[PATCH] D113237: [RISCV] Support I extension version 2.1

[Kito Cheng via Phabricator via cfe-commits]

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