Zicntr and Zihpm are names for groups of CSRs so they should imply
that CSRs exist.
Reviewed By: asb, kito-cheng
Differential Revision: https://reviews.llvm.org/D148962
As was documented in D147183, we don't currently intend to support
multiple versions of specifications simultaneously. While external
circumstances might mean exceptions to this are needed, the TODOs about
reflecting version numbers in the feature strings no longer make sense.
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
As noted in https://reviews.llvm.org/D148315, the ordering logic for
OrderedExtensionMap currently puts s* before z* extensions, but per the
ISA manual the correct order should be z* and then s* (with the
exception of zxm*, which are ordered after s*).
This patch fixes the ordering and adds a TODO for zxm*. The changes are
visible in the test case added in
a35e67fc5be654a7efdfa6125343b90f8960a487 which also demonstrates an
issue with the ordering of single letter extensions (which isn't
addressed in this patch).
This ordering matches the one used by GCC/binutils as well.
Differential Revision: https://reviews.llvm.org/D148615
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
According to latest risc-v spec, the canonical order in which extension names must appear in the name string specified in Table 29.1 is different from before. In the latest table, non-standard extensions must be listed after all standard extensions. To keep consistent, we now change the parsing order in parseArchString().
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D148315
New versions I2.1, F2.2, D2.2 A2.1
Make F and Zfinx imply Zicsr.
Make G imply Zifencei.
This should have no impact to generated code. We have no plans to require Zicsr/Zifencei extension to be explicitly enabled to use Zicsr/Zifencei instructions in assembly.
See https://reviews.llvm.org/D147183 for documentation regarding what version specification we implement.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D147179
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
Tools such as llvm-objdump will currently inputs when the base ISA has
an unrecognised version. I addressed a similar issue in LLD in D144353,
introducing parseArchStringNormalized. While it would make sense to
migrate `llvm/lib/Object/ELFObjectFile.cpp` to using
`parseArchStringNormalized` as well, this patch takes a less ambitious
initial step. By tweaking the behaviour of `parseArchString` when
`IgnoreUnknown` is true (which only has one in-tree user), we use the
default supported ISA version when a base ISA with unrecognised version
is encountered.
This means that llvm-objdump and related tools will function better for
objects produced from a recent GCC. This isn't a full fix, as
IgnoreUnknown means that an imafd object with attributes specifying
newer A/F/D versions will have those extensions ignored.
Differential Revision: https://reviews.llvm.org/D146070
parseNormalizedArchString adds a code path that creates a RISCVISAInfo
including extensions that may not be supported by LLVM (rather than
erroring or just ignoring them). Therefore, toFeatureVector needs to
check the extension is supported in order to avoid creating unrecognised
feature strings.
This change shouldn't impact any code paths used outside of test code,
but this will be relied upon by the next patch which moves llvm-objdump
and related tools over to using parseNormalizedArchString.
Differential Revision: https://reviews.llvm.org/D146113
RV32E was recently [ratified](afd613691c) so we should update the version as our MC-layer support is complete.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D144384
Instead of having a separate single letter and multiletter ranking
use a unified rank that assigns multiletter a larger value than
single letter.
Once we've ranked the extensions, then we compare using these ranks.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D146273
This field is never used in the compiler and was only used in
unit tests added recently.
It's only used as the value in a map where the extension name
is the key. If we need the string we can get it from the key.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D146197
RISCVISAInfo::parseArchString would sometimes error for arch strings
with a trailing _ and sometimes accept them. This patch makes it
consistently error.
Differential Revision: https://reviews.llvm.org/D145949
There is no versioning scheme for the 'g' shorthand for imafd (or in
current ISA specs, imafd_zifencei_zicsr). As such, the only sensible
behaviour to me seems to be to reject a version for it.
Differential Revision: https://reviews.llvm.org/D145954
Prior to this patch, unrecognised z/s/sx/x prefixed extensions were not
ignored when IgnoreUnknown=true.
The first version of this patch, a7313f83b9ca9, incorrectly used
`!isSupportedExtension(Ext)` rather than `!isSupportedExtension(Name)`.
i.e. checked the full substring rather than the split out name, causing
incorrect behaviour when a version is specified. This was fixed and a
new test case addded.
Differential Revision: https://reviews.llvm.org/D145882
Prior to this patch, unrecognised z/s/sx/x prefixed extensions were not
ignored when IgnoreUnknown=true.
Differential Revision: https://reviews.llvm.org/D145882
I believe this implies relationship is documented in the current
spec but may have been less clear in an older spec.
We used to report an error so I think it should be ok to change this.
Only someone expecting the error should be impacted.
Reviewed By: asb, luismarques
Differential Revision: https://reviews.llvm.org/D145125
This patch follows on from this RFC thread
<https://discourse.llvm.org/t/rfc-resolving-issues-related-to-extension-versioning-in-risc-v/68472/>
and the ensuing discussion in the RISC-V LLVM sync-up call. The
consensus agreed that the behaviour change in LLD introduced in D138550
that results in object files including arch attributes with unrecognised
extensions or versions of extensions is a regression and should be
treated as such. As it stands, this logic means that LLD will error out
if trying to link a RISC-V object file from LLVM HEAD (rv32i2p0/rv64i2p0)
with one from current GCC (rv32i2p1/rv64i2p1 by default).
There's a bigger discussion about exactly when to warn vs error and so
on, and how to control that, and this patch doesn't attempt to address
all those questions. It simply tries to fix the problem with a minimally
invasive change, intended to be cherry-picked for 16.0.x (ideally
16.0.0, but queued for 16.0.1 if we're too late in the release cycle).
As you can see from the test changes, although the changed logic is
mostly more permissive, it will reject some embedded arch strings that
were accepted before. Because the same logic was previously used for
parsing human-written -march as for the arch attribute (intended to be
stored in normalised form), various short-hand formats were previously
accepted. Maintaining support for such ill-formed attributes would
substantially complicate the logic, and given the previous
implementation was so much stricter in every other way, was surely a bug
rather than a design choice.
Surprisingly, the precise rules for how numbers can be embedded into
extension names isn't fully defined (there is a PR to the ISA manual
that is not yet merged
<https://github.com/riscv/riscv-isa-manual/pull/718>).
In the absence of specific criteria for rejecting extensions names that
would be ambiguous in abbreviated form,
`RISCVISAInfo::parseArchStringNormalized` just pulls out the version
information from the end of each extension description.
Differential Revision: https://reviews.llvm.org/D144353
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
Experimental support for the zfa extension was recently added in https://reviews.llvm.org/D141984. A couple of the normal test changes and clang plumbing got missed in that change. This commit updates the usual suspects.
Differential Revision: https://reviews.llvm.org/D144288
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
