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
For the most part, MC version of vector instructions don't model when
the destination is also a source. This primarily occurs for mask/tail
undisturbed. The MC layer can't see the policy bits so this kind of
makes sense.
We also lumped FMA instructions into this, but the destination of
FMA is an arithmetic source not just an undisturbed value. This needs
to be correct for llvm-mca to understand the dependency for the FMA
instructions. Though every other instruction is still wrong for
tail/mask undisturbed.
This patch models the FMA instructions correctly at the MCA layer.
This necessitates changes to the assembler to offset operand numbers.
I've added the extra sched class operand and fixed the operand order
for the scalar read class.
Reviewed By: rogfer01
Differential Revision: https://reviews.llvm.org/D151850
Since the spec doesn't describe these behaviors as invalid,
the llvm-mc should just make them take care by hardware.
Differential Revision: https://reviews.llvm.org/D155669
Support for below CSRs is addeed -
1. Branch Prediction Mode CSR
2. Feature Disable CSR
3. Power Dial CSR
4. RNMI CSRs
spec:https://sifive.cdn.prismic.io/sifive/767804da-53b2-4893-97d5-b7c030ae0a94_s76mc_core_complex_manual_21G3.pdf
This patch removes AltName field from SysReg class because we are now using
separate class for custom vendor CSRs. Also, all use of AltName have been changed
to DeprecatedName because both were interchangeably used for old names which are
not in use in latest RISCV spec.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D153499
We were checking that the encoding within our internal list of
registers was even. This worked today because X0 happens to have
an even value in that enum. This can break if any registers are
added before X0.
The correct check is to make sure it has an even offset from X0.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D155104
This implements the v1.0-rc1 draft extension.
amocas.d on RV32 and amocas.q have the restriction that rd and rs2 must
be even registers. I've opted to implement this restriction in
RISCVAsmParser::validateInstruction even though for codegen we'll need a
new register class and can then remove this validation. This also
sidesteps, for now, the issue of amocas.d being different on rv32 vs
rv64.
See <https://github.com/riscv-non-isa/riscv-c-api-doc/issues/37> for the
issue of needing an agreed asm register constraint for register pairs.
Differential Revision: https://reviews.llvm.org/D149248
ParseStatus is slightly more convenient to use due to implicit
conversion from bool, which allows to do something like:
```
return Error(L, "msg");
```
when with MatchOperandResultTy it had to be:
```
Error(L, "msg");
return MatchOperand_ParseFail;
```
It also has more appropriate name since parse* methods are not only for
parsing operands.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D154291
In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.
Otherwise subsequent .option arch, +foo directives (but not -, since
those have their own separate validation) fail the parseFeatureBits
check, leading to cascading errors.
Reviewed By: luismarques, MaskRay
Differential Revision: https://reviews.llvm.org/D152273
The current interface requires some rather ugly tracking of state due to
splitting up the calls for each argument. Instead, pack them all into a
single call by passing an ArrayRef. Also clean up the dodgy whitespace
emitted for the directive whilst here; there was a stray space between
the tab and .option, and there was a tab rather than a space after the
first comma for some strange reason.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D152193
Currently the early-return flow in the infinite loop makes it hard to
find the non-error termination points amongst the sea of errors. Rewrite
it with a more conventional control flow that has a clear loop guard (in
place of one of the early returns) and a break (in place of the other),
and with greater code reuse.
This has a small effect on the errors given for malformed input, as seen
in the affected test, and is probably more helpful as a result. Note
that we also bail early now if parseComma fails, as is standard.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D152192
This mirrors lla and is always GOT-relative, allowing an explicit
request to use the GOT without having to expand the instruction. This
then means la is just defined in terms of lla and lga in the assembler,
based on whether PIC is enabled, and at the codegen level we replace la
entirely with lga since we only ever use la there when we want to load
from the GOT (and assert that to be the case).
See https://github.com/riscv-non-isa/riscv-asm-manual/issues/50
Reviewed By: asb, MaskRay
Differential Revision: https://reviews.llvm.org/D107278
Probably going to do some other refactors after this, but this one
was easy and clearly reduces duplicate code.
Reviewed By: StephenFan
Differential Revision: https://reviews.llvm.org/D151771
Previously we lexed into a SmallVector and unlexed the tokens if
the parsing failed.
This patch gets rid of the SmallVector and the unlexing.
If the first token fails to parse, return MatchFail. This allows us
to fallback to parsing as an immediate. If we successfully parsed the
first token, use ParseFail if any later tokens fail to parse. This
avoids needing to UnLex the tokens.
I've used a state machine to keep track of what component we've
parsed so far.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D150753
This patch lets the assembler accept code like the following:
.Lbuf: ...
.set .Lbuf_len, . - .Lbuf
li a0, .Lbuf_len
It works by translating such instances of LI into an ADDI and inserting
the correct constant value via a new fixup.
Note that this means that the constant value is restricted to 12 bits
since we cannot insert new instructions during the relaxation stage.
Binutils seems to have the same restriction though.
This patch also fixes a small issue where the SMLoc of an LI wasn't
propagated when translated to ADDI. While this is technically unrelated
to the main functionality of this patch, it improves error messages
related to the new use of LI.
This patch does _not_ allow I-type instructions to take such symbolic
constants as well. While technically possible (and allowed by binutils),
it's probably better to implement this in another patch.
Fixes#57461
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D135960
This previously returned a bool to indicate success or failure and
returns a register through an output parameter.
Some callers used the bool to check for success. Some callers checked
for RISCV::NoRegister.
To make everything uniform, return the MCRegister directly and update
all callers to use MCRegister::isValid().
Reviewed By: barannikov88
Differential Revision: https://reviews.llvm.org/D150049
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
