As suggested by Craig, this tries to merge the two sets of register
classes created in #112983, GPRPair* and GPRF64Pair*.
- I added some explicit annotations to `RISCVInstrInfoD.td` which fixed
the type inference issues I was seeing from tablegen for select
patterns.
- I've had to make the behaviour of `splitValueIntoRegisterParts` and
`joinRegisterPartsIntoValue` cover more cases, because you cannot
bitcast to/from untyped (the bitcast would otherwise have been inserted
automatically by TargetLowering code).
- I apparently didn't need to change `getNumRegisters` again, which
continues to tell me there's a bug in the code for tied inputs. I added
some more test coverage of this case but it didn't seem to help find the
asserts I was finding before - I think the difference is between the
default behaviour for integers which doesn't apply to floats.
- There's still a difference between BuildGPRPair and BuildPairF64 (and
the same for SplitGPRPair and SplitF64). I'm not happy with this, I
think it's quite confusing, as they're very similar, just differing in
whether they give a `untyped` or a `f64`. I haven't really worked out
how the DAGCombiner copes if one meets the other, I know we have some of
this for the f64 variants already, but they're a lot more complex than
the GPRPair variants anyway.
This patch adds support for getting even-odd general purpose register
pairs into and out of inline assembly using the `R` constraint as
proposed in riscv-non-isa/riscv-c-api-doc#92
There are a few different pieces to this patch, each of which need their
own explanation.
- Renames the Register Class used for f64 values on rv32i_zdinx from
`GPRPair*` to `GPRF64Pair*`. These register classes are kept broadly
unmodified, as their primary value type is used for type inference
over selection patterns. This rename affects quite a lot of files.
- Adds new `GPRPair*` register classes which will be used for `R`
constraints and for instructions that need an even-odd GPR pair. This
new type is used for `amocas.d.*`(rv32) and `amocas.q.*`(rv64) in
Zacas, instead of the `GPRF64Pair` class being used before.
- Marks the new `GPRPair` class legal as for holding a `MVT::Untyped`.
Two new RISCVISD node types are added for creating and destructing a
pair - `BuildGPRPair` and `SplitGPRPair`, and are introduced when
bitcasting to/from the pair type and `untyped`.
- Adds functionality to `splitValueIntoRegisterParts` and
`joinRegisterPartsIntoValue` to handle changing `i<2*xlen>` MVTs into
`untyped` pairs.
- Adds an override for `getNumRegisters` to ensure that `i<2*xlen>`
values, when going to/from inline assembly, only allocate one (pair)
register (they would otherwise allocate two). This is due to a bug in
SelectionDAGBuilder.cpp which other backends also work around.
- Ensures that Clang understands that `R` is a valid inline assembly
constraint.
- This also allows `R` to be used for `f64` types on `rv32_zdinx`
architectures, where doubles are stored in a GPR pair.
Make it a pseudoinstruction so we can convert it to C_NOP. This makes
the printing from the assembler consistent with what we get from
llvm-objdump.
I tried to do this with an InstAlias, but I don't think it can drop
operands.
When assembling raw instructions, often you want to or together several
fields for clarity, or because you're using an assembly macro with
separate arguments.
This brings the use of `.insn` closer into line with what can be done
with the binutils assembler.
The 64-bit instruction test here explicitly sets the top bit to make
sure this works, even though the assembler is really using `int64_t`
in most places internally.
This adds `.insn` support for assembling instructions of 48- and
64-bits (only when giving an explicit length). Disassembly already
knows to bunch up the instruction bits for these instructions.
This changes some error messages so they are a little clearer.
Co-authored-by: Sudharsan Veeravalli <quic_svs@quicinc.com>
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 can convert the MCRegister to bool instead. I think this should
allows us to remove MCRegister::operator==(int). All other comparisons
in tree are unsigned.
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 PR is a follow-up of PR #96174 which added the framework to resolve
encoding conflicts among vendor specific CSRs. This PR explicitly
enables this only for the RISCV target.
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.
This patch adds support for the following two hardcode encodings of
.insn directive:
```
.insn <insn-length>, <value>
.insn <value>
```
See also gas's patch
a262b82fdb
NOTE: This patch doesn't support long instructions.
Closes https://github.com/llvm/llvm-project/issues/97498.
According to RVV spec:
> In general, the requirement is to support LMUL ≥ SEWMIN/ELEN,
> where SEWMIN is the narrowest supported SEW value and ELEN is
> the widest supported SEW value.
>
> For a given supported fractional LMUL setting, implementations
> must support SEW settings between SEWMIN and LMUL * ELEN, inclusive.
We print a warning if these requirements are not met.
Reviewers: kito-cheng, asb, frasercrmck, jrtc27, michaelmaitland, lukel97
Reviewed By: lukel97
Pull Request: https://github.com/llvm/llvm-project/pull/94313
These larger SEWs aren't in the ratified V spec. Thanks to dzaima and
sorear on IRC for pointing this one out.
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Previously `.option arch` denied extenions are not belongs to RISC-V
features. But experimental features have experimental- prefix, so
`.option arch` can not serve for experimental extension.
This patch uses the features of extensions to identify extension
existance.
This introduces a new file, RISCVISAUtils.cpp and moves the rest of
RISCVISAInfo to the TargetParser library.
This will allow us to generate part of RISCVISAInfo.cpp using tablegen.
Both calls to parseVTypeToken were proceeded by check for an Identifier
token and a call to getIdentifier. Sync those into the parseVTypeToken
to reduce repetition.
Planning to declare all extensions in tablegen so we can generate the
tables for RISCVISAInfo.cpp. This requires making "e" consistent with
other extensions.
The usage of IsEABI was only valid for RV32E. For RV64E, the stack
adjust
base needs to be 32 when ra,s0-s1 are being saved. Since it takes more
than 16 bytes to save 3 64-bit registers.
The spec lists the rv32e behavior explicitly, but not rv64e. My
assumption is that the only thing that changes with rv64e is which
registers can be used in the register list, but not how the register
list affects the stack_adj_base.
To do this I've added a new AsmOperand for cm.push to expect a negative
value. We also use that to customize the print function so that we don't
need to detect cm.push opcode to add the negative sign.
I've renamed some places that used Spimm to be StackAdj since that's
what is being parsed. I'm still not about where we should use Spimm or
StackAdj.
I've removed the printSpimm helper function which in one usage printed
the sp[5:4]<<4 value and the other usage printed the full stack
adjustment. There wasn't anything interesting about how it was printed
it just passed the value to the raw_stream. If there was something
special needed, it's unclear whether it would be the same for the two
different usages so I inlined it.
One open question is whether we need to support stack adjustments
expressed as an expression rather than a literal integer.
We had "+zca" instead of "zca". The previous line used "c", not "+c".
This may not be a functional change. I think the function we pass this
to strips any '+' or '-'.
This patch adds basic TLSDESC support in the RISC-V backend.
Specifically, we add new relocation types for TLSDESC, as prescribed in
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373, and add a
new pseudo instruction to simplify code generation.
This patch does not try to optimize the local dynamic case, which can be
improved in separate patches.
Linker side changes will also be handled separately.
The current implementation is only enabled when passing the new
`-enable-tlsdesc` codegen flag.
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.
R_RISCV_CALL/R_RISCV_CALL_PLT distinction is not necessary and
R_RISCV_CALL has been deprecated. Since https://reviews.llvm.org/D132530
`call foo` assembles to R_RISCV_CALL_PLT. The `@plt` suffix is not
useful and can be removed now (matching AArch64 and PowerPC).
GNU assembler assembles `call foo` to RISCV_CALL_PLT since 2022-09
(70f35d72ef04cd23771875c1661c9975044a749c).
Without this patch, unconditionally changing MO_CALL to MO_PLT could
create `jump .L1@plt, a0`, which is invalid in LLVM integrated assembler
and GNU assembler.
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.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
This seems to be an issue common to both GCC and LLVM. There are various
RISC-V FCVT instructions where the frm field makes no difference to the
output as the result is always exact (e.g. fcvt.d.s, fcvt.s.h,
fcvt.d.h). As with GCC, we always generate a form of these fcvt
instructions where frm=0b000. However, the ISA manual _doesn't_ state
that frm values are invalid, and we should ensure we can accept them.
This patch does so by adding the frm field to fcvt.d.s and adding an
InstAlias so that if no frm is specified, it defaults to rne (0b000).
This patch just corrects fcvt.d.s in order to allow the approach to be
reviewed, before applying it to the other affected instructions.
I haven't added tests to llvm/test/MC/Disassembler/RISCV, because it
doesn't seem necessary to test there in addition to our usual round-trip
tests in llvm/test/MC/RISCV. But feedback is welcome.
Recently added tests ensure that the default `rne` rounding mode is
printed as desired.
This finishes the work of replacing OperandMatchResultTy with
ParseStatus, started in D154101.
As a drive-by change, rename some RegNo variables to just Reg
(a leftover from the days when RegNo had 'unsigned' type).
According to `riscv-v-spec-1.0.pdf` page 52:
> masked va >= x, vd == v0
> pseudoinstruction: vmsge{u}.vx vd, va, x, v0.t, vt
> expansion: vmslt{u}.vx vt, va, x; vmandn.mm vd, vd, vt
The resulting `vmslt{u}.vx` is not masked. This patch fixes the logic in `RISCVAsmParser`, to make the behavior consistent with the case "masked va >= x, any vd" in the later part of the code, where no mask op is added.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D158392
