Update the Zvk support from 0.3.x to 0.5.1, tracking the extension as
documented in
<https://github.com/riscv/riscv-crypto/releases/download/v20230407/riscv-crypto-spec-vector.pdf>.
- Zvkb is split into Zvbb and Zvbc
- Zvbc (vector carryless multiply) requires 64 bit elements (Zve64x)
- Use the extension descriptions from the specification for Zvbb/Zvbc
- Zvkt is introduced (no instructions, but adds an attribute and macro)
- Zvkn and Zvks both imply Zvkt
- Zvkng and Zvksg are introduced, adding Zvkg (GMAC) to Zvkn and Zvks
- In Zvbb, add vrev.v, vclz.v, vctz.v, vcpop.v, vwsll.{vv,vx,vi}
Differential Revision: https://reviews.llvm.org/D148483
2a5661c8415876be3fbd56ce90c2031e89ba0ef3 added a new external link with
the link text "0.2 draft specification". Surprisingly, as multiple links
have this same text but different targets this causes a warning, which
causes a failure on the llvm-sphinx-docs builder (which treats warnings
as errors). As suggested in
<https://github.com/sphinx-doc/sphinx/issues/3921>, this commit moves to
using anonymous references for the links in the experimental extensions
section.
As of
1f03818281
in the riscv-isa-manual, Zfa is at version 0.2. Reviewing the commit
history for
zfa.tex
<https://github.com/riscv/riscv-isa-manual/commits/master/src/zfa.tex>
there are no relevant changes since 0.1. As such, we can simply
increment the version number.
This change also removes the claim in RISCVUsage that we implement a
"subset of" Zfa, as I believe this is no longer true. That sentence
previously incorrectly claimed we didn't implement fli.{h,s,d} (I
[corrected this a couple of weeks
ago](https://reviews.llvm.org/rG3d969191b277)) but I think should have
removed the "subset of" wording too.
As was noted during the review, we never added Zfa to the release notes.
This is corrected in this patch.
Differential Revision: https://reviews.llvm.org/D148634
This is intended to document the decision made in recent discussion, and ratified at the last risc-v sync up call two weeks ago.
The wording here turned out to be a bit tricky. I ended up using the word "revision" as the specification internally defines several versioning schemes, and RVI assigns particular meaning to the words "specification version" that I really didn't want to get into. If anyone has suggestions on how to improve this, please don't hesitate to chime in.
Differential Revision: https://reviews.llvm.org/D147183
This patch adds the basic MC layer support for Zicond, based on
[1.0-rc1](https://github.com/riscv/riscv-zicond/releases/tag/v1.0-rc1).
As with other extensions, if there are additional changes between
release candidates without incrementing the version number we won't be
able to reflect that in the version number. I believe we've previously
decided this is not a problem for extensions still considered
experimental (i.e. not yet ratified).
Differential Revision: https://reviews.llvm.org/D146946
Support for the unratified 1.0-rc3 specification was introduced in
D133443. The specification has since been ratified (in November 2022
according to the recently ratified extensions list
<https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions>.
A review of the diff
<https://github.com/riscv/riscv-zawrs/compare/V1.0-rc3...main> of the
1.0-rc3 spec vs the current/ratified document shows no changes to the
instruction encoding or naming. At one point, a note was added
<e84f42406a>
indicating Zawrs depends on the Zalrsc extension (not officially
specified, but I believe to be just the LR/SC instructions from the A
extension). The final text ended up as "The instructions in the Zawrs
extension are only useful in conjunction with the LR instructions, which
are provided by the A extension, and which we also expect to be provided
by a narrower Zalrsc extension in the future." I think it's consistent
with this phrasing to not require the A extension for Zawrs, which
matches what was implemented.
No intrinsics are implemented for Zawrs currently, meaning we don't need
to additionally review whether those intrinsics can be considered
finalised and ready for exposure to end users.
Differential Revision: https://reviews.llvm.org/D143507
(Opening comment by preames - submitter, not patch author)
Try 1 was reverted because it had been landed in pieces, none of which had a meaningful commit message.
Try 2 was reverted because of a buildbot failure. It turns out this was a spurious revert on my (preames) part. The buildbots were failing, and it was from one of my changes in this sequence, but not the recommit. I had reverted both of the try 1 commits in a single git push, but in separate *commits*. Some of the builders decided to build the broken state between the original try 1 commit, and I'd not noticed that. I'd assumed the breakage was because of the try2 re-commit. So the revert of the try 2 recommit was spurious.
Original commit message:
This implements experimental support for the RISCV Zfa extension as specified here: https://github.com/riscv/riscv-isa-manual/releases/download/draft-20221119-5234c63/riscv-spec.pdf, Ch. 25. This extension has not been ratified. Once ratified, it'll move out of experimental status.
This change adds assembly support for all instructions except load-immediate instructions (fli.s/fli.d/fli.h). Assembly support for that instruction and codegen support will follow in separate patches.
Differential Revision: https://reviews.llvm.org/D141984
This change adds the definition of the two extensions, but does not either a) make any instruction conditional on them or b) enabled the extensions by default. (The *instructions* do remain enabled by default per ISA version 2.0 which is our current default.)
This is meant to be a building block towards something like https://reviews.llvm.org/D141666, and in the meantime, address one of the most surprising of the current user experience warts. The current behavior of rejecting the extensions at the command line despite emitting code which appears to use them is surprising to anyone not deeply versed in the details of this situation.
Between versions 2.0 and 2.1 of the base I specification, a backwards incompatible change was made to remove selected instructions and CSRs from the base ISA. These instructions were grouped into a set of new extensions (these), but were no longer required by the base ISA. This change is described in “Preface to Document Version 20190608-Base-Ratified” from the specification document.
As LLVM currently implements only version 2.0 of the base specification, accepting these extensions at the command line introduces a configuration which doesn't actually match any spec version. It's a pretty harmless variant since the 2.0 extension definitions, to my knowledge, exactly match the text from the 2.0 I text before they were moved into standalone extensions in 2.1 of I. (The version numbering in that sentence is a tad confusing to say the least. Hopefully I got it right.)
It is worth noting that we already have numerous examples of accepting extensions in the march string which didn't exist in version of the spec document corresponding to our current base I version, so this doesn't set any new precedent.
Differential Revision: https://reviews.llvm.org/D143953
This implements experimental support for the RISCV Zfa extension as specified here: https://github.com/riscv/riscv-isa-manual/releases/download/draft-20221119-5234c63/riscv-spec.pdf, Ch. 25. This extension has not been ratified. Once ratified, it'll move out of experimental status.
This change adds assembly support for all instructions except load-immediate instructions (fli.s/fli.d/fli.h). Assembly support for that instruction and codegen support will follow in separate patches.
Differential Revision: https://reviews.llvm.org/D141984
This has been a repeated point of recent confusion. There are a couple attempts in flight to change the way we handle the extensions, but for the moment, let's just document what's going on.
Differential Revision: https://reviews.llvm.org/D14392
This patch reorder the list of Experimental Extensions in doc,
and change the spec verision in doc to match the actual Implementation
if this patch is so small that it is not worth to submit separately, Apologies for bothering
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D143908
This change implements a proposed lowering from LLVM's memory model to the TSO memory model defined by the Ztso extension. Selecting the proposed mapping turns out to be an involved conversation that really didn't fit within a review description, so let me refer you to https://github.com/preames/public-notes/blob/master/riscv-tso-mappings.rst. This review implements the WMO compatible variant (the proposed one in that document).
Ztso is currently accepted as an experimental extension in LLVM. Despite the fact the extension was recently ratified, I think we need to leave it as experimental until we have wide agreement on the chosen mapping for ABI purposes.
I need to note that the current in-tree implementation defaults to generating WMO compatible fences. This is entirely compatible with the proposed mapping in this patch, but is unfortunately not compatible with the major alternative. The in tree implementation is explicitly experimental so the impact of this is limited, but it is worth calling out that if settle on the alternative we will have a minor ABI break. My apologies for not calling this out in the original patch; I had not realized at the time that one of our realistic choices for mappings wouldn't be WMO compatible.
This patch only contains the changes for load/store and fence. That is, it does not change the lowering for atomicrmw operations. This is a sound thing to do under the proposed mapping since the existing WMO mappings remain compatible. I do plan to change these; I'm just working incrementally.
Differential Revision: https://reviews.llvm.org/D143076
This patch add the instructions of Zcb extension.
Instructions in zcb extensions shorten part of bit manipulation instructions.
Co-authored-by: Craig Topper <craig.topper@sifive.com>
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D131141
`h` was the prefix of multi-letter extension name, but it become a
extension name in later RISC-V isa spec.
Fortunately we don't have any extension really defined is prefixed
with `h`, so we can just change that.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D136817
