These were in LLVM 17 but removed from LLVM 18 due to an incorrect
extension name being used.
This restores them with new extension names that match SiFive's
downstream compiler. The extension name has been used internally for
some time. It uses XSiFive instead of XSf like the newer extensions.
`cease` did not have an internal extension name so its using the `XSf`
convention.
The spec for the instructions is here
https://sifive.cdn.prismic.io/sifive/767804da-53b2-4893-97d5-b7c030ae0a94_s76mc_core_complex_manual_21G3.pdf
though the extension name is not listed.
Column width in the extension printing had to be changed to accommodate
a longer extension name.
If the "march" has some extension with version that is not supported, it
returns the error message like: "error: invalid arch name 'some_arch',
unsupported version number 2.0 for extension 'some_arch'", which is not
precise enough, it should return the message that only tells users "the
extension is not supported".
This patch implements the v0.8.1 specification. This patch reports
version 0.8 in llvm since `RISCVISAInfo::ExtensionVersion` only has a
`Major` and `Minor` version number. This patch includes includes support
of the `Ssnpm`, `Smnpm`, `Smmpm`, `Sspm` and `Supm` extensions that make
up RISC-V pointer masking.
All of these extensions require emitting attribute containing correct
`march` string.
`Ssnpm`, `Smnpm`, `Smmpm` extensions introduce a 2-bit WARL field (PMM).
The extension does not specify how PMM is set, and therefore this patch
does not need to address this. One example of how it *could* be set is
using the Zicsr instructions to update the PMM bits of the described
registers.
The full specification can be found at
https://github.com/riscv/riscv-j-extension/blob/master/zjpm-spec.pdf
This is a good portion of the extensions mentioned in the RVA23 profile
here
https://github.com/riscv/riscv-profiles/blob/main/rva23-profile.adoc
I don't believe these add any new CSRs. Sstc does add new CSRs, but we
already added them without the extension name a while back.
I tried to keep the descriptions in RISCVFeatures.td fairly short since
the strings show up in `-print-supported-extensions`.
With std::move added to fix build bot failure.
Original commit message:
Follow
https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/14 by
dropping the order requirement of `-march`.
1. single-letter extension can be arbitrary order
- march=rv32iamdf
2. single-letter extension and multi-letter extension can be mixed
- march=rv32i_zihintntl_m_a_f_d_svinval
3. multi-letter extension need seperate the following extension by
underscore, otherwise it will be intreprete as one extension.
- march=rv32i_zbam -> i,zbam
- march=rv32i_zba_m -> i,zba,m
Follow
https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/14 by
dropping the order requirement of `-march`.
1. single-letter extension can be arbitrary order
- march=rv32iamdf
2. single-letter extension and multi-letter extension can be mixed
- march=rv32i_zihintntl_m_a_f_d_svinval
3. multi-letter extension need seperate the following extension by
underscore, otherwise it will be intreprete as one extension.
- march=rv32i_zbam -> i,zbam
- march=rv32i_zba_m -> i,zba,m
The Zicond extension was ratified in the last few months, with no
changes that affect the LLVM implementation. Although there's surely
more tuning that could be done about when to select Zicond or not, there
are no known correctness issues. Therefore, we should mark support as
non-experimental.
We were converting several StringRefs to std::strings then to
char * so we could pass as %s to a format string. Use the Twine
signature of createStringError instead.
This adds minimal support for 7 new unprivileged extensions that were
defined as a part of
the RISC-V Profiles specification here:
https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#7-new-isa-extensions
* Ziccif: Main memory supports instruction fetch with atomicity
requirement
* Ziccrse: Main memory supports forward progress on LR/SC sequences
* Ziccamoa: Main memory supports all atomics in A
* Zicclsm: Main memory supports misaligned loads/stores
* Za64rs: Reservation set size of 64 bytes
* Za128rs: Reservation set size of 128 bytes
* Zic64b: Cache block size isf 64 bytes
As stated in the specification, these extensions don't add any new
features but
describe existing features. So this patch only adds parsing and
subtarget
features.
This commit includes the necessary changes to clang and LLVM to support
codegen of `RVE` and the `ilp32e`/`lp64e` ABIs.
The differences between `RVE` and `RVI` are:
* `RVE` reduces the integer register count to 16(x0-x16).
* The ABI should be `ilp32e` for 32 bits and `lp64e` for 64 bits.
`RVE` can be combined with all current standard extensions.
The central changes in ilp32e/lp64e ABI, compared to ilp32/lp64 are:
* Only 6 integer argument registers (rather than 8).
* Only 2 callee-saved registers (rather than 12).
* A Stack Alignment of 32bits (rather than 128bits).
* ilp32e isn't compatible with D ISA extension.
If `ilp32e` or `lp64` is used with an ISA that has any of the registers
x16-x31 and f0-f31, then these registers are considered temporaries.
To be compatible with the implementation of ilp32e in GCC, we don't use
aligned registers to pass variadic arguments and set stack alignment\
to 4-bytes for types with length of 2*XLEN.
FastCC is also supported on RVE, while GHC isn't since there is only one
avaiable register.
Differential Revision: https://reviews.llvm.org/D70401
We have two structs for representing the version of an extension in
RISCVISAInfo, RISCVExtensionInfo and RISCVExtensionVersion, both
with the exact same fields. This patch deduplicates them.
toFeatures and toFeatureVector both output a list of target feature
flags, just with a slightly different interface. toFeatures keeps any
unsupported extensions, and also provides a way to append negative
extensions (AddAllExtensions=true).
This patch combines them into one function, so that a later patch will
be be able to get a std::vector of features that includes all the
negative extensions, which was previously only possible through the
StrAlloc interface.
The patch adds the instructions in Zicfiss extension. Zicfiss extension
is to support shadow stack for control flow integrity. This patch is
based on version [0.3.1].
[0.3.1]: https://github.com/riscv/riscv-cfi/releases/tag/v0.3.1
This reverts 0d3eee33f2 and
4c37d30e22.
XSfcie is not an official SiFive extension name. It stands for
SiFive Custom Instruction Extension, which is mentioned in the S76
manual, but then elsewhere in the manual says it is not supported
for S76.
LLVM had various instructions and CSRs listed as part of this
extension, but as far as SiFive is concerned, none of them are part
of it. There are no documented extension names for these instructions
and CSRs either externally or internally.
If these are important to LLVM users, I can facilitate creating
extension names for them and have them documented. For now I'm
removing everything.
Unfortunately, these instructions and CSRs are in LLVM 17 so this
is an incompatible change.
Zvfbfmin does not have any scalar operands making this an unnecessary
dependency. The spec was just updated to remove this. See
https://github.com/riscv/riscv-bfloat16/commit/86d7a74f4b928e981f79f6d84a4592e6e9e4c0e9
This fixes a correctness issue where Xsfvfwmaccqqq was incorrectly
depending on Zfbfmin. The SiFive CPUs that support Xsfvfwmaccqqq do not
implement Zfbfmin, but do implement Zvfbfmin based on a previous
understanding that it only requires Zve32f. I've added tests for this
feature to raise the bar for adding dependencies to it in the future.
The RISC-V vector crypto extensions have been ratified. This patch
updates the Clang and LLVM support for these extensions to be
non-experimental, while leaving the C intrinsics as experimental since
the C intrinsics are not yet standardized.
Co-authored-by: Brandon Wu <brandon.wu@sifive.com>
Following the version bump in #67964 and the bug fix in #68026 I believe
we're ready to mark Zfa as non-experimental. I'll note the GCC torture
suite passes now with Zfa enabled (though it's more of a litmus test
than anything else).
The Zfa specification was recently ratified
<https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions>. This
commit bumps the version to 1.0, but leaves it as an experimental
extension (to be done in a follow-on patch), so reviews can focus on
confirming there haven't been spec changes we have missed (which as
noted below, is more difficult than usual).
Because the development of the Zfa spec overlapped with the transition
of riscv-isa-manual from LaTeX to AsciiDoc, it's more difficult than
usual to confirm version changes. The linked PDF in RISCVUsage is for
some reason a 404. Key commit histories to review are:
* Changes to zfa.adoc on the main branch
<https://github.com/riscv/riscv-isa-manual/commits/main/src/zfa.adoc>
* Changes to zfa.tex on the now defunct latex branch
<https://github.com/riscv/riscv-isa-manual/commits/latex/src/zfa.tex>
From reviewing these, I believe there have been no changes to the spec
since version 0.1/0.2 (sadly the AsciiDoc and LaTeX versions of the spec
are inconsistent about version numbering).
Pengcheng Wang
Craig Topper
Brandon Wu
Michael Maitland
Yingwei Zheng
Piyou Chen
Mehdi Amini
Alex Bradbury
Min-Yih Hsu
Luke Lau
Yeting Kuo
Yvan Roux
Eric BiggersandBrandon Wu
Jianjian Guan
LiaoChunyu
Shao-Ce SUNandJun Sha
Simon Pilgrim