This patches adds a 32 bit register class for use with Zfinx instructions. This makes them more similar to F instructions and allows us to only spill 32 bits.
I've added CodeGenOnly instructions for load/store using GPRF32 as that gave better results than insert_subreg/extract_subreg.
Function arguments use this new GPRF32 register class for f32 arguments with Zfinx. Eliminating the need to use RISCVISD::FMV* nodes.
This is similar to #107446 which adds a 16 bit register class.
This patches adds a 16 bit register class for use with Zhinx
instructions. This makes them more similar to Zfh instructions and
allows us to only spill 16 bits.
I've added CodeGenOnly instructions for load/store using GPRF16 as that
gave better results than insert_subreg/extract_subreg. I'm using FSGNJ
for GPRF16 copy with Zhinx as that gave better results. Zhinxmin will
use ADDI+subreg operations.
Function arguments use this new GPRF16 register class for f16 arguments
with Zhinxmin. Eliminating the need to use RISCVISD::FMV* nodes.
I plan to extend this idea to Zfinx next.
We were missing test coverage for fneg.d/fabs.d for Zdinx. When I
added it revealed it only worked on RV64. The assembler was not
creating a GPRPair register class on RV32 so the alias couldn't match.
The disassembler was also not using GPRPair registers preventing the
aliases from printing in disassembly too.
I've fixed the assembler by adding new parsing methods in an attempt
to get decent diagnostics. This is hard since the mnemonics are
ambiguous between D and Zdinx. Tests have been adjusted for some
differences in what errors are reported first.
This extension consists of 8 additional 16-bit compressed forms for
existing standard load/store opcodes.
These opcodes are found in some RISC-V microcontrollers from WCH /
Nanjing Qinheng Microelectronics.
As discussed in the Discourse forums, this uses incompatible extension
and opcode names vs the vendor binary toolchain. The chosen names
instead follow the conventions for other vendor extensions listed on the
"riscv-non-isa" project.
We don't have any instructions defined yet, but that we can still read the correct number of bytes when disassembling. This should better match GNU objdump behavior.
We're decoding a 1 bit field, but checked that the value was <= 2
instead of <= 1.
This isn't a functional change because the generated disassembler code
that calls this only extracts 1 bit.
Planning to declare all extensions in tablegen so we can generate the
tables for RISCVISAInfo.cpp. This requires making "e" consistent with
other extensions.
These were in LLVM 17 but removed from LLVM 18 due to an incorrect
extension name being used.
This restores them with new extension names that match SiFive's
downstream compiler. The extension name has been used internally for
some time. It uses XSiFive instead of XSf like the newer extensions.
`cease` did not have an internal extension name so its using the `XSf`
convention.
The spec for the instructions is here
https://sifive.cdn.prismic.io/sifive/767804da-53b2-4893-97d5-b7c030ae0a94_s76mc_core_complex_manual_21G3.pdf
though the extension name is not listed.
Column width in the extension printing had to be changed to accommodate
a longer extension name.
This changes the register class to GPRPair and adds the destination
register as a source with a tied operand constraint.
Parsing for the paired register is done with a custom parser that
checks for even register and converts it to its pair version. A
bit of care needs to be taken so that we only parse as a pair register
based on which instruction we're parsing and the mode in the subtarget.
This allows amocas.w to be parsed correcty in both modes.
I've added a FIXME to note that we should be creating pair registers
for Zdinx on RV32 to match the instructions CodeGen generates.
-Rename to GPRPair.
-Rename registers to be named like X10_X11 instead of X10_PD. Except X0
which is now X0_Pair since it is not paired with X1.
-Use unknown size and offset for the subreg indices. This might
be a functional change, but does not affect any lit tests.
The patch adds the instructions in Zicfiss extension. Zicfiss extension
is to support shadow stack for control flow integrity. This patch is
based on version [0.3.1].
[0.3.1]: https://github.com/riscv/riscv-cfi/releases/tag/v0.3.1
This reverts 0d3eee33f262402562a1ff28106dbb2f59031bdb and
4c37d30e22ae655394c8b3a7e292c06d393b9b44.
XSfcie is not an official SiFive extension name. It stands for
SiFive Custom Instruction Extension, which is mentioned in the S76
manual, but then elsewhere in the manual says it is not supported
for S76.
LLVM had various instructions and CSRs listed as part of this
extension, but as far as SiFive is concerned, none of them are part
of it. There are no documented extension names for these instructions
and CSRs either externally or internally.
If these are important to LLVM users, I can facilitate creating
extension names for them and have them documented. For now I'm
removing everything.
Unfortunately, these instructions and CSRs are in LLVM 17 so this
is an incompatible change.
Implement XCVbi intrinsics for CV32E40P according to the specification.
This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P.
Contributors: @CharKeaney, @jeremybennett, @lewis-revill, @liaolucy, Nandni Jamnadas, @paolos, @simoncook, @xmj.
bf2ad26b4ff856aab9a62ad168e6bdefeedc374f originally commited.
e4777dc4b9cb371971523cc603e1b8a5c7255e7e reverted due to test failures caused by a merge conflict marker in llvm/test/CodeGen/RISCV/attributes that was accidentally checked in.
This commit removed the conflict marker and recommitted.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D154412
Implement XCVbi intrinsics for CV32E40P according to the specification.
This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P.
Contributors: @CharKeaney, @jeremybennett, @lewis-revill, @liaolucy, Nandni Jamnadas, @PaoloS, @simoncook, @xmj.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D154412
Implement XCVsimd intrinsics for CV32E40P according to the specification.
This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P.
Contributors: @CharKeaney, @jeremybennett, @lewis-revill, @liaolucy, Nandni Jamnadas, @PaoloS, @simoncook, @xmj.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D153721
Implement XCValu intrinsics for CV32E40P according to the specification.
This is a commit of the patch-set to upstream the 7 vendor specific extensions of CV32E40P.
Contributors: @CharKeaney, Nandni Jamnadas, Serkan Muhcu, @jeremybennett, @lewis-revill, @liaolucy, @simoncook, @xmj
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D153748
Implement XCVmac intrinsics for CV32E40P according to the specification.
This is the first commit of a patch-set to upstream the 7 vendor specific extensions of CV32E40P.
The patch-set aims at upstreaming the extensions on MC. The following will be on CodeGen, and the final patch-set will be on builtins if possible. The implemented version is on [0].
Contributors: @CharKeaney, Serkan Muhcu, @jeremybennett, @lewis-revill, @liaolucy, @simoncook, @xmj
Spec: 62bec66b36/docs/source/instruction_set_extensions.rst
[0] https://github.com/openhwgroup/corev-llvm-project
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D152821
Implement XCVbitmanip intrinsics for CV32E40P according to the specification.
This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P.
Contributors: @CharKeaney, @jeremybennett, @lewis-revill, @liaolucy, @simoncook, @xmj.
Spec: 62bec66b36/docs/source/instruction_set_extensions.rst
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D152915
The decoding parts are reduplicative, we add a macro to simplify
the code.
Reviewed By: craig.topper, kito-cheng
Differential Revision: https://reviews.llvm.org/D151309
Previously we added the SP operands when an immediate operand was added
to certain opcodes.
This patch moves it to a post processing step using the information
in MCInstrDesc. This avoids an explicit opcode list in RISCVDisassembler.cpp.
In considered using a custom DecoderMethod, but the bit swizzling we
need to do for the immediates on these instructions made that
unattractive.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D149931
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 Zcmt instructions overlap encoding space with some C extension
instructions. Isolate to a separate namespace.
Reviewed By: VincentWu
Differential Revision: https://reviews.llvm.org/D149891
Rather than using operator[] on getFeatureBits we can use
hasFeature to shorten the code.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D144300
