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.
|360 ms||x64 debian > Clang.Driver::riscv-arch.c|
Script: -- : 'RUN: at line 1'; /var/lib/buildkite-agent/builds/llvm-project/build/bin/clang --target=riscv32-unknown-elf -march=rv32i -### /var/lib/buildkite-agent/builds/llvm-project/clang/test/Driver/riscv-arch.c -fsyntax-only 2>&1 | /var/lib/buildkite-agent/builds/llvm-project/build/bin/FileCheck /var/lib/buildkite-agent/builds/llvm-project/clang/test/Driver/riscv-arch.c
|270 ms||x64 debian > Clang.Preprocessor::riscv-target-features.c|
Script: -- : 'RUN: at line 1'; /var/lib/buildkite-agent/builds/llvm-project/build/bin/clang -target riscv32-unknown-linux-gnu -march=rv32i -x c -E -dM /var/lib/buildkite-agent/builds/llvm-project/clang/test/Preprocessor/riscv-target-features.c -o - | /var/lib/buildkite-agent/builds/llvm-project/build/bin/FileCheck /var/lib/buildkite-agent/builds/llvm-project/clang/test/Preprocessor/riscv-target-features.c
|300 ms||x64 debian > LLVM.CodeGen/RISCV::attributes.ll|
Script: -- : 'RUN: at line 3'; /var/lib/buildkite-agent/builds/llvm-project/build/bin/llc -mtriple=riscv32 /var/lib/buildkite-agent/builds/llvm-project/llvm/test/CodeGen/RISCV/attributes.ll -o - | /var/lib/buildkite-agent/builds/llvm-project/build/bin/FileCheck /var/lib/buildkite-agent/builds/llvm-project/llvm/test/CodeGen/RISCV/attributes.ll
|120 ms||x64 debian > LLVM.MC/RISCV::attribute-arch.s|
Script: -- : 'RUN: at line 3'; /var/lib/buildkite-agent/builds/llvm-project/build/bin/llvm-mc /var/lib/buildkite-agent/builds/llvm-project/llvm/test/MC/RISCV/attribute-arch.s -triple=riscv32 -filetype=asm | /var/lib/buildkite-agent/builds/llvm-project/build/bin/FileCheck /var/lib/buildkite-agent/builds/llvm-project/llvm/test/MC/RISCV/attribute-arch.s
|80 ms||x64 debian > LLVM.MC/RISCV::attribute-with-insts.s|
Script: -- : 'RUN: at line 5'; /var/lib/buildkite-agent/builds/llvm-project/build/bin/llvm-mc -triple riscv32 -filetype=obj /var/lib/buildkite-agent/builds/llvm-project/llvm/test/MC/RISCV/attribute-with-insts.s | /var/lib/buildkite-agent/builds/llvm-project/build/bin/llvm-objdump --triple=riscv32 -d -M no-aliases - | /var/lib/buildkite-agent/builds/llvm-project/build/bin/FileCheck -check-prefix=CHECK-INST /var/lib/buildkite-agent/builds/llvm-project/llvm/test/MC/RISCV/attribute-with-insts.s
|View Full Test Results (14 Failed)|
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.
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
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
- [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