This is an archive of the discontinued LLVM Phabricator instance.

[RISCV] Proper support of extensions Zicsr and Zifencei
AbandonedPublic

Authored by eklepilkina on Jan 13 2023, 1:02 AM.

Details

Summary

Specification describes extensions Zicsr and Zifencei, but LLVM now include all instructions from these extensions by default. GCC supports both of these extensions as described in specification.

Diff Detail

Event Timeline

eklepilkina created this revision.Jan 13 2023, 1:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 13 2023, 1:02 AM
eklepilkina requested review of this revision.Jan 13 2023, 1:02 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptJan 13 2023, 1:02 AM
eklepilkina edited the summary of this revision. (Show Details)Jan 13 2023, 1:10 AM

We are interested in proper support for Zicsr and Zifencei. Could someone look at patch or explain why these extensions were included by default?

Because they used to be part of I and then a later version of the RISC-V spec split them out in an incompatible way. GCC/binutils bit the bullet and split them out last(?) year but LLVM has yet to make that breaking change.

asb added a comment.Jan 17 2023, 6:05 AM

We are interested in proper support for Zicsr and Zifencei. Could someone look at patch or explain why these extensions were included by default?

As Jessica says, the reason they're not split out is that when the backend was first implemented, they were part of the I specification. I'm not at all a fan of how this happened, but we are where we are, and as noted GCC has made this change. The key aspect this patch misses right now is the versioning issue - I is still marked as 2.0. So really, this needs someone to propose a what the change will look like in full. A few misc thoughts (and all of these would need some more discussion with others active in the RISC-V backend). e.g. do we need/want -misa-version, or is there a proposal to just move to I 2.1 by default?

It might also be interesting to explore options that temporarly sidestep the versioning discussion and improve compatibility with GCC -march strings. e.g. an initial patch that adds zicsr and zifencei but enables it by default (or otherwise handles zicsr and zifencei as a no-op). I _think_ I'd be happy with something along those lines, but I can't speak for others involved in the RISC-V backend.

Thank you for comments!

The key aspect this patch misses right now is the versioning issue - I is still marked as 2.0.

I can update I extension version or separate diffrent isa versions as you mentioned. I can fix comments and make proposed by community changes. We are interested in supporting compatibility with GCC.

It might also be interesting to explore options that temporarly sidestep the versioning discussion and improve compatibility with GCC -march strings. e.g. an initial patch that adds zicsr and zifencei but enables it by default (or otherwise handles zicsr and zifencei as a no-op)

We internally made something similar, just added extensions in the list and ignore warnings in some places. But still these extensions are already ratified so proper support is needed to be done some time

  • Updated I extension verson

Maybe multi-lib handling should split into another patch?

eklepilkina added a comment.EditedJan 20 2023, 9:15 AM

Maybe multi-lib handling should split into another patch?

I can do this. But if I separate I still can't choose one that should be merged firstly, they will be needed to merge both at once, because tests will fail. If separate them right way (fixes for multilibs in baremetal.cpp and gnu.cpp). Shall I separate?

JFYI, I have a change out which just documents current status while we wait for a resolution. https://reviews.llvm.org/D143924

@reames Thank you for fixing documentation, missed this

  • [RISCV] Prepare work to be ready for adding separate Zicsr and Zifencei extensions
  • [RISCV] Proper support of extensions Zicsr and Zifencei
  • Updated I extension verson
  • Fixing after updating
eklepilkina abandoned this revision.Apr 20 2023, 5:59 AM

Another implementation was merged to upsteam