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
After D153170 the tables are now sorted by extension name so we can use that to
avoid a linear search.
Reviewed By: asb, MaskRay
Differential Revision: https://reviews.llvm.org/D153598
This was committed with D153598 merged into it. Reverting to recommit as separate patches.
This reverts commit 690b1c847f0b188202a86dc25a0a76fd8c4618f4.
For the same reasons as D151284, this requires custom lowering of the
truncate libcall on hard float ABIs (the normal libcall code path is
used on soft ABIs).
The extend operation is implemented by a shift just as in the standard
legalisation, but needs to be custom lowered because i32 isn't a legal
type on RV64.
This patch aims to make the minimal changes that result in correct
codegen for the bfloat.ll tests.
Differential Revision: https://reviews.llvm.org/D151663
As the extension list continues to grow it probably makes sense
to use a binary search rather than linear search. Sorting the strings
will make this possible.
This also avoids any question about where to add new strings in
the tables.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D153170
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
Update the RISC-V Zvk (vector cryptography) extension support from 0.5
to version 0.9.7 (2023-05-31), per
<https://github.com/riscv/riscv-crypto/releases/download/v20230531/riscv-crypto-spec-vector.pdf>
Differences:
- Zvbc is dropped from Zvkn and Zvks, and by extension
from Zvkng and Zvksg;
- new combo extensions Zvknc and Zvksc are introduced,
adding Zvbc to Zvkn and Zvks;
- the experimentatl extensions are tagged as "0.9",
from the earlier "0.5".
Reviewed By: 4vtomat
Differential Revision: https://reviews.llvm.org/D152117
Encountered ASAN crash and found it dereference without check pointer.
Reviewed By: kito-cheng, eklepilkina
Differential Revision: https://reviews.llvm.org/D151716
This reverts commit 35a0079238ce9fc36cdc8c6a2895eb5538bf7b4a.
The backend support is not present yet. The intrinsics will crash
the compiler if compiled to assembly or binary.
Our current approach is that if one extension requires another, we make
LLVM treat it as implied. My initial zfbfmin patch failed to do this for
the F extension (documented as a requirement of zfbfmin). This patch
fixes that.
Differential Revision: https://reviews.llvm.org/D151096
Provides MC layer support for Zvfbfwma: vector BF16 widening mul-add.
As currently specified, Zvfbfwma does not appear to have a dependency on
Zvfbfmin or Zfbfmin.
Differential Revision: https://reviews.llvm.org/D147612
Provides MC layer support for Zfbfmin: vector BF16 conversions.
Zvfbfmin does not appear to have a dependency on Zfbfmin as currently
specified.
Differential Revision: https://reviews.llvm.org/D147611
Provides MC layer support for Zfbfmin: scalar BF16 conversions.
As documented, this extension includes FLH, FSH, FMV.H.X, and FMH.X.H as
defined in Zfh/Zfhmin, but doesn't require either extension.
No Zfbfinxmin has been defined (though you would expect one in the
future, for symmetry with Zfhinxmin). See issue
https://github.com/riscv/riscv-bfloat16/issues/27.
Differential Revision: https://reviews.llvm.org/D147610
According to the v spec, the Zvfh extension depends on the Zve32f and Zfhmin extensions.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D150016
This patch add the instructions of zcmp extension.
Instructions in zcmp extension try to optimise `mv` inst and the prologue & epilogue in functions
co-author: @Scott Egerton, @ZirconLiu, @Lukacma, @Heda Chen, @luxufan, @heyiliang, @liaochunyu
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D132819
The 1.0 vector spec PDF has text that says that Zve32f is compatible
with F or Zfinx and that Zve64d is compatible with D and Zdinx.
The references to *inx were removed from the spec in the github repository in
October 2021. The 1.0 pdf was made in September 2021.
Relevant commit 6fedb869e2
Reviewed By: jacquesguan
Differential Revision: https://reviews.llvm.org/D150021
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
