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
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
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 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
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
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
As suggested by @asb [here](https://reviews.llvm.org/D143570#4112877), we need tests for `.attribute stack_align`. This patch simply verifies a stack alignment of 16 is emitted for any combination of currently supported base ISA and extensions.
Reviewed By: asb, kito-cheng
Differential Revision: https://reviews.llvm.org/D143639
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
This patch add the support of RISCV Zca ext
`Zca` is a subset of C extension instructions that are compatible with the Zc extension.
So this patch implements Zca code generation with reference to the C extension and sets the 2-byte alignment for the Zca extension, just like C extension does.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D130483
This change provides an implementation of the XVentanaCondOps vendor extension. This extension is defined in version 1.0.0 of the VTx-family custom instructions specification (https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf) by Ventana Micro Systems.
In addition to the technical contribution, this change is intended to be a test case for our vendor extension policy.
Once this lands, I plan to use this extension to prototype selection lowering to conditional moves. There's an RVI proposal in flight, and the expectation is that lowering to these and the new RVI instructions is likely to be substantially similar.
Differential Revision: https://reviews.llvm.org/D137350
This extension does not appear to be on its way to ratification.
Out of the unratified bitmanip extensions, this one had the
largest impact on the compiler.
Posting this patch to start a discussion about whether we should
remove these extensions. We'll talk more at the RISC-V sync meeting this
Thursday.
Reviewed By: asb, reames
Differential Revision: https://reviews.llvm.org/D133834
This implements experimental support for the Zawrs extension as specified here: https://github.com/riscv/riscv-zawrs/releases/download/V1.0-rc3/Zawrs.pdf. Despite the 1.0 version name, this has not been ratified and there was a major change to proposed specification between rc2 and rc3. Once this is ratified, it'll move out of experimental status.
This change adds assembly support, but does not include C language or IR intrinsics. We can decide if we want them, and handle that in a separate patch.
Differential Revision: https://reviews.llvm.org/D133443
This is a minimalist implementation which simply adds the extension (in the experimental namespace since its not ratified), and wires up the setting of the required ELF header flag. Future changes will include codegen changes to exploit the stronger memory model.
This is intended to implement v0.1 of the proposed specification which can be found in Chapter 25 of https://github.com/riscv/riscv-isa-manual/releases/download/draft-20220723-10eea63/riscv-spec.pdf.
Differential Revision: https://reviews.llvm.org/D133239
This patch implements recently ratified extension Zmmul, a subextension
of M (Integer Multiplication and Division) consisting only
multiplication part of it.
Differential Revision: https://reviews.llvm.org/D103313
Reviewed By: craig.topper, jrtc27, asb
