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).
This revision supports --print-supported-extensions,
it prints out all of the extensions and corresponding version supported.
Reviewed By: craig.topper, kito-cheng
Differential Revision: https://reviews.llvm.org/D146054
Some ISAInfo unittest base on experimental-zihintntl, but zihintntl will become none-experimental. This patch use another experimental extension zicond to replace zihintntl.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155673
According to the spec, Zce is an alias for Zca, Zcb, Zcmp, and Zcmt.
If F is enabled on RV32 it also includes Zcf.
This patch adds the Zce and the implication rule which unfortunately
requires custom handling for adding Zcf.
I've also made all the Zc* extensions imply Zca.
I've also added an error for Zcf without RV32.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D153742
This was discussed somewhat in D148315. As it stands, we require in
RISCVISAInfo::parseArchString (used for e.g. -march parsing in Clang)
that extensions are given in the order of z, then s, then x prefixed
extensions (after the standard single-letter extensions). However, we
recently (in D148315) moved to that order from z/x/s as the canonical
ordering was changed in the spec. In addition, recent GCC seems to
require z* extensions before s*.
My recollection of the history here is that we thought keeping -march as
close to the rules for ISA naming strings as possible would simplify
things, as there's an existing spec to point to. My feeling is that now
we've had incompatible changes, and an incompatibility with GCC there's
no real benefit to sticking to this restriction, and it risks making it
much more painful than it needs to be to copy a -march= string between
GCC and Clang.
This patch removes all ordering restrictions so you can freely mix x/s/z
extensions.
To be very explicit, this doesn't change our behaviour when emitting a
canonically ordered extension string (e.g. in build attributes). We of
course sort according to the canonical order (as we understand it) in
that case.
Differential Revision: https://reviews.llvm.org/D149246
We already had an error for Zcmt though it appears to be untested
Add similar one for Zcmp along with tests for both.
Factor the code to share the strings as much as possible.
Reviewed By: VincentWu
Differential Revision: https://reviews.llvm.org/D153159
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
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
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
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
D144343 added C++ unit tests for the newly added
RISCVISAInfo::parseArchStringNormalized. This patch adds test coverage
for parseArchString and the toFeatureVector member method.
Posting for review as it would be useful if someone can take a quick
look to check they don't feel I've missed testing an important aspect of
the current behaviour.
Differential Revision: https://reviews.llvm.org/D145879
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
