There are a couple bugs in the current support for this:
-We do all the parsing in single precision so any value less than or
equal to the minimum fp32 is accepted as the minimum value for f64.
-To support fp16 minimum value, getLoadFP32Imm has a special case, but
that causes a miscompile in CodeGen.
Differential Revision: https://reviews.llvm.org/D145542
Instead of converting to FP value, store them as Index using an
immediate operand.
Do the same for the explicit index form.
This avoids using the FP32 version of these special values as the
representation for fli.h and fli.d. inf/nan aren't so bad, but
"min" is problematic as the current implementation allows fli.d and
fli.h to accept the decimal version of the fp32 minimum value. I
will submit another patch to fix that.
Differential Revision: https://reviews.llvm.org/D145535
MatchOperand_NoMatch will fall back to regular operand parsing.
Returning MatchOperand_ParseFail will prevent this.
We also printed our own error message which we should only do for
MatchOperand_ParseFail.
This implements experimental support for the RISCV Zfa extension as specified here: https://github.com/riscv/riscv-isa-manual/releases/download/draft-20221119-5234c63/riscv-spec.pdf, Ch. 25. This extension has not been ratified. Once ratified, it'll move out of experimental status.
This change adds assembly support for load-immediate instructions (fli.s/fli.d/fli.h). The assembly prefers decimal constants in C-like syntax. In my implementation, an integer encoding ranging from 0 to 31 can also be accepted, but for the MCInst printer, the constant is specified in decimal notation by default.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D140460
Rather than using operator[] on getFeatureBits we can use
hasFeature to shorten the code.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D144300
Internally we store constants in int64_t after parsing, but this is
kind of an implementation detail. If we only supported rv32, we might
have chosen int32_t.
For rv32, I think it makes sense to accept the constants that we
would accept if int32_t was the internal type. In fact we already
do this for the `li` alias. This patch extends this to sign
extended constants for other instructions.
This matches the GNU assembler. The difference between LLVM and gcc
was previously noted here. https://github.com/riscv-non-isa/riscv-asm-manual/pull/71
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D144166
(Opening comment by preames - submitter, not patch author)
Try 1 was reverted because it had been landed in pieces, none of which had a meaningful commit message.
Try 2 was reverted because of a buildbot failure. It turns out this was a spurious revert on my (preames) part. The buildbots were failing, and it was from one of my changes in this sequence, but not the recommit. I had reverted both of the try 1 commits in a single git push, but in separate *commits*. Some of the builders decided to build the broken state between the original try 1 commit, and I'd not noticed that. I'd assumed the breakage was because of the try2 re-commit. So the revert of the try 2 recommit was spurious.
Original commit message:
This implements experimental support for the RISCV Zfa extension as specified here: https://github.com/riscv/riscv-isa-manual/releases/download/draft-20221119-5234c63/riscv-spec.pdf, Ch. 25. This extension has not been ratified. Once ratified, it'll move out of experimental status.
This change adds assembly support for all instructions except load-immediate instructions (fli.s/fli.d/fli.h). Assembly support for that instruction and codegen support will follow in separate patches.
Differential Revision: https://reviews.llvm.org/D141984
This implements experimental support for the RISCV Zfa extension as specified here: https://github.com/riscv/riscv-isa-manual/releases/download/draft-20221119-5234c63/riscv-spec.pdf, Ch. 25. This extension has not been ratified. Once ratified, it'll move out of experimental status.
This change adds assembly support for all instructions except load-immediate instructions (fli.s/fli.d/fli.h). Assembly support for that instruction and codegen support will follow in separate patches.
Differential Revision: https://reviews.llvm.org/D141984
And remove the IsRV64 checks for isGPRAsFPR and isGPRPF64AsFPR.
Overall I think this results in a better diagnostic experience. We
now do a better job of matching Zdinx instructions even if the registers
aren't correct and report an error for missing features like RV64.
Unfortunately, this makes it difficult to recover the error location
for the invalid odd register when we do report it. But to make up
for it, I gave a more specific error message.
It doesn't look like binutils gives any warning or error for odd registers.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D142997
Instead of having InstAliases without operand. Use the optional
operand infrastructure.
Still use the PrintAliases/NoAlias controls to determine if we
print "dyn" or not.
Differential Revision: https://reviews.llvm.org/D142959
Rather than parsing a symbol and checking its name, look for an
identifier during parsing.
I've also handled the 0 immediate during parsing, though we could
let that go through the normal immediate parsing if we need to support
expressions that evaluate to 0. We don't have tests for that currently.
Reviewed By: asb, frasercrmck
Differential Revision: https://reviews.llvm.org/D142865
We don't need this field for all operand types, so sync it into the
ones that do need it. Then remove it from the create* functions that
don't need it.
This field is only initialized for register operands, move it into
the struct to make that clear.
This also fixes a potential bug where the field wasn't copied by
the RISCVOperand copy constructor.
Previously we parsed it as a symbol, and then accessed the name.
This works, but seems like an unusual way to do it.
This adds a custom parser that looks for an Identifier token containing
one of the valid FRM strings.
Differential Revision: https://reviews.llvm.org/D142833
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
We have several usages of compressInst/uncompressInst in different
files, which results in duplicated code. We move their implementations
to RISCVBaseInfo under namespace RISCVRVC to remove these duplications.
Reviewed By: craig.topper, asb
Differential Revision: https://reviews.llvm.org/D141897
This was being used to lookup the register class for a register number,
but those live in a tablegened array. We can index that array directly
just like RISCVAsmParser does.
Differential Revision: https://reviews.llvm.org/D141951
The patch is split from D103435. The patch supported a new directive .variant_cc
that annotates function with STO_RISCV_VARIANT_CC. Symbols marked with
STO_RISCV_VARIANT_CC do not use standard calling conversion or use parameter not
passed in GPR/FPR.
Related: https://github.com/riscv/riscv-elf-psabi-doc/pull/190
Initial authored by: HsiangKai
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D138352
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
X86 and ARM AsmParsers have this same assertion. This assertion provides better reporting when the RISCVTargetStreamer is null and helps to prevent null pointer access.
Reviewed By: bkramer
Differential Revision: https://reviews.llvm.org/D132863
Instead of matching opcodes to know the format to emit, use an
enum value that we can get from the RISCVMatInt::Inst class.
Change the consumers to use fully covered switches so that we get
a compiler warning if a new kind is added. With the opcode checks
it was easier to forget to update one of the 3 consumers.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D126317
In the past, when construct RISCVAsmBackend, MCTargetOptions.ABIName would be passed and stored in RISCVAsmBackend.
But MCTargetOptions.ABIName can only be specified by -target-abi xxx in command line, if the .ll file has target-abi attribute, the codegen module will ignore it. And the generated object file would have incorrect EFlags value.
https://github.com/llvm/llvm-project/issues/50591 also caused by this problem.
This patch override the AsmPrinter::emitFunctionEntryLabel function and use it to set the target abi value that get from .ll file's target-abi attribute. And storing the target-abi in RISCVTargetStreamer instead of RISCVAsmBackend.
Differential Revision: https://reviews.llvm.org/D121183
This patch added the MC layer support of Zfinx extension.
Authored-by: StephenFan
Co-Authored-by: Shao-Ce Sun
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D93298
Not only some AMO instructions but also other instructions need to
process (${gpr}) or 0(${gpr}), where the 0 is be silently ignored.
This patch does some changes for general usage.
Signed-off-by: Eric Tang <eric.tang@starfivetech.com>
Differential Revision: https://reviews.llvm.org/D120017
