pli.h and pli.w both accept signed immediates, so pli.b should too. But
unlike those instructions, pli.b doesn't do any extension so its ok to
accept an unsigned immediate as well.
There's a long comment explaining this approach in RISCVInstrInfoXqci.td
This change also fixes some problems when fixups are able to be resolved for `qc.e.li` and `qc.li`.
Instead of allowing a parsed MCInst to have a either uimm10 or simm10,
always render as simm10. This avoids a mismatch between parsed MCInst
and disassembled MCInst when a uimm10 value is used.
Printing an expression is error-prone without a MCAsmInfo argument.
Remove the operator<< overload and replace callers with
MCAsmInfo::printExpr. Some callers are changed to MCExpr::print, with
the goal of eventually making it private.
so that subclasses can provide the appropriate MCAsmInfo to print
MCExpr objects.
At present, llvm/utils/TableGen/AsmMatcherEmitter.cpp constucts a
generic MCAsmInfo.
This matches the current binutils behaviour, and the orignal ratified
spec that states that LMUL=1 when the lmul operand is omitted. A variety
of previously invalid vtype instructions are now accepted by the
assembler.
To match binutils, at least one of the vtype operands must be provided.
Also fixes the MCOperandPredicate definition in VTypeIOp, which had one
logic issue and one syntax issue. This is not used by the MC layer
currently, so this change should not affect the existing implementation.
Fixes#143744
As of 20b5728b7b1ccc4509a316efb270d46cc9526d69, C always enables Zca, so
the check `C || Zca` is equivalent to just checking for `Zca`.
This replaces any uses of `HasStdExtCOrZca` with a new `HasStdExtZca`
(with the same assembler description, to avoid changes in error
messages), and simplifies everywhere where C++ needed to check for
either C or Zca.
The Subtarget function is just deprecated for the moment.
This patch adds support for parsing symbols in the XAndesPerf branch
immediate instructions. The branch immediate instructions use
`R_RISCV_NDS_BRANCH_10` relocation. It uses a 10-bit PC-relative branch
offset.
## Purpose
This patch is one in a series of code-mods that annotate LLVM’s public
interface for export. This patch annotates the `llvm/Target` library.
These annotations currently have no meaningful impact on the LLVM build;
however, they are a prerequisite to support an LLVM Windows DLL (shared
library) build.
## Background
This effort is tracked in #109483. Additional context is provided in
[this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307),
and documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).
A sub-set of these changes were generated automatically using the
[Interface Definition Scanner (IDS)](https://github.com/compnerd/ids)
tool, followed formatting with `git clang-format`.
The bulk of this change is manual additions of `LLVM_ABI` to
`LLVMInitializeX` functions defined in .cpp files under llvm/lib/Target.
Adding `LLVM_ABI` to the function implementation is required here
because they do not `#include "llvm/Support/TargetSelect.h"`, which
contains the declarations for this functions and was already updated
with `LLVM_ABI` in a previous patch. I considered patching these files
with `#include "llvm/Support/TargetSelect.h"` instead, but since
TargetSelect.h is a large file with a bunch of preprocessor x-macro
stuff in it I was concerned it would unnecessarily impact compile times.
In addition, a number of unit tests under llvm/unittests/Target required
additional dependencies to make them build correctly against the LLVM
DLL on Windows using MSVC.
## Validation
Local builds and tests to validate cross-platform compatibility. This
included llvm, clang, and lldb on the following configurations:
- Windows with MSVC
- Windows with Clang
- Linux with GCC
- Linux with Clang
- Darwin with Clang
* Move getPCRelHiFixup closer to the only caller RISCVAsmBackend::evaluateTargetFixup.
* Declare getSpecifierForName in RISCVMCAsmInfo, in align with other
targets that have migrated to the new relocation specifier representation.
Follow-up to #140494
`shouldForceRelocation` is conservative and produces redundant
relocations.
For example, RISCVAsmBackend::ForceRelocs (introduced to support mixed
relax/norelax code) leads to redundant relocations in the following
example adapted from #77436
```
.option norelax
j label
// For assembly input, RISCVAsmParser::ParseInstruction sets ForceRelocs (https://reviews.llvm.org/D46423).
// For direct object emission, RISCVELFStreamer sets ForceRelocs (#77436)
.option relax
call foo // linker-relaxable
.option norelax
j label // redundant relocation due to ForceRelocs
.option relax
label:
```
Root problem: The `isSymbolRefDifferenceFullyResolvedImpl` condition in
MCAssembler::evaluateFixup does not check whether two locations are
separated by a fragment whose size can be indeterminate due to linker
instruction (e.g. MCDataFragment with relaxation, or MCAlignFragment
due to indeterminate start offst).
This patch
* Updates the fragment walk code in
`attemptToFoldSymbolOffsetDifference` to treat MCRelaxableFragment
(for --riscv-asm-relax-branches) as fixed size after finishLayout.
* Adds a condition in `addReloc` to complement
`isSymbolRefDifferenceFullyResolvedImpl`.
* Removes the no longer needed `shouldForceRelocation`.
This fragment walk code path handles nicely handles
mixed relax/norelax case from
https://discourse.llvm.org/t/possible-problem-related-to-subtarget-usage/75283
and allows us to remove `MCSubtargetInfo` argument (#73721) as a follow-up.
This fragment walk code should be avoided in the absence of
linker-relaxable fragments within the current section.
Adjust two bolt/test/RISCV tests (#141310)
Pull Request: https://github.com/llvm/llvm-project/pull/140692
This adds assembler/disassembler support for XSfmmbase 0.6 and related
SiFive matrix multiplication extensions based on the spec here
https://www.sifive.com/document-file/xsfmm-matrix-extensions-specification
Functionality-wise, this is the same as the Zvma extension proposal that
SiFive shared with the Attached Matrix Extension Task Group. The
extension names and instruction mnemonics have been changed to use
vendor prefixes.
Note this is a non-conforming extension as the opcodes used here are in
the standard opcode space in OP-V or OP-VE.
---------
Co-authored-by: Brandon Wu <brandon.wu@sifive.com>
... as they map directly and we don't utilize -Wswitch.
Retained VK_*_LO constants for lowering to LO_I or LO_S.
The Sparc port has eliminated all Specifier constants (commit
003fa7731d81a47c98e9c55f80d509933c9b91f6), and the LoongArch port is
nearly free of them (#138632).
Pull Request: https://github.com/llvm/llvm-project/pull/138644
The assembly parser was checking for any register instead of GPR.
I've removed the custom diagnostic message from the RegReg operand to
give a less confusing error on bad input. The mnemonics are shared with
other encodings that don't use reg-reg memory operand.
I also fixed the parsed operand location, but I'm not sure it matters.
Follow-up to the just landed #135044 . Remove `@plt` parsing (only
needed by legacy `call foo@plt`). MCParser's `@` parsing is problematic.
Supporting target variations like (`foo+2@plt foo@plt+2 (foo+2)@plt`)
involves messy hacks. We should refrain from adding new `@` uses.
Remove unneeded `RISCVMCExpr::VK_QC_E_JUMP_PLT` (should only be used
when an instruction might have multiple reasonable relocations
https://maskray.me/blog/2025-03-16-relocation-generation-in-assemblers).
---
GCC's initial initial RISC-V port made a mistake by having both `call
foo` (non-PIC) and `call foo@plt` (PIC), likely misled by x86/SystemZ.
It was determined that the `@plt` was not needed. Since R_RISCV_CALL had
questionable undefined weak semantics in GNU ld (which has been removed
then), we kept R_RISCV_CALL_PLT and deprecated R_RISCV_CALL.
For RISC-V instructions, we only keep `@` in call/jump for backward
compatibility and discourage it for all other instructions.
(
There is disagreement about whether `PLT` in `JUMP_PLT` is useful or
misleading.
MaskRay's opnion: For new branch relocations with procedure call
semantics, use `_CALL` and avoid `_PLT` in the relocation name.
`_PLT` should only be used in data directives (e.g. R_RISCV_PLT32) to
indicate that the address of a function is not significant.
)
Pull Request: https://github.com/llvm/llvm-project/pull/135507
Structure the code into a loop that parses a series of ranges and gives
an error when there are too many ranges.
Give errors when ABI and non-ABI names are mixed.
Properly diagnose 'x1-` starting a list.
Use a default bool argument to merge parseRegListCommon and
parseRegList.
This patch adds support for parsing symbols in the Xqcilb long branch
instructions. The instructions use the `R_RISCV_QC_E_JUMP_PLT`
relocation and the `InstFormatQC_EJ` instruction format.
Vendor relocation support will be added in a later patch.
This patch adds support for parsing symbols in the Xqcili load large
immediate instructions. The 32 bit `qc.li` instructions uses the
`R_RISCV_QC_ABS20_U` relocation while the 48 bit `qc.e.li` instruction
uses the `R_RISCV_QC_E_32` relocation and the `InstFormatQC_EAI`
instruction format.
Vendor relocation support will be added in a later patch.
This adds support for 'ld \<rd\> \<symbol\>' and 'sd \<rd\>, \<symbol\>,
\<rt\>' to match what we do for RV32.
I've changed the interface to emitAuipcInstPair to use MCRegister
instead of MCOperand since we need to convert a GPRPair to GPR for
TmpReg for the load case.
This adds `qc.e.l<type> <reg>, <symbol>` and `qc.e.s<type> <reg>,
<symbol>, <reg>` pseudos for the corresponding Xqcilo instructions.
These emit as an AUIPC + (Standard) Load/Store pair, because this
sequence is shorter and can be relaxed back into the equivalent Xqcilo
load/store instruction in the right circumstances.
We will replace the MCSymbolRefExpr member in MCValue with MCSymbol.
This change reduces dependence on MCSymbolRefExpr.
Creating a MCSymbolRefExpr in *AsmBackend::handleAddSubRelocations is
not efficient, but it is temporary and will be replaced when MCValue no
longer uses MCSymbolRefExpr.
Spimm in the spec refers to the 2-bit encoded value. All of the code
uses the 0, 16, 32, or 48 adjustment value.
Also remove the decodeZcmpSpimm as its identical to the default
behavior for no custom DecoderMethod.
This way we emit the error message that explains the full syntax
for a register list.
parseZcmpStackAdj had to be modified to not assume the previous
operand had been successfully parsed as a register list.
Move the parsing of '-' under the check that we parsed a comma.
Unfortunately, this leads to a poor error, but I still have more known
issues in this code and may end up with an overall restructuring and
want to think about wording.
This is more of a semantic check. The diagnostic location to has been
changed to point at the register list start instead of the
closing brace or whatever character might be there instead of a brace
if its malformed.
This adds the following instruction formats from the Xqci Spec:
- QC.EAI
- QC.EI
- QC.EB
- QC.EJ
- QC.ES
The update to the THead test is because the largest number of operands
for a valid instruction has been bumped by this change.
This reverts commit 68fb7a5a1d203dde7badf67031bdd9eb650eef5d. This
relands commit 0cfabd37df9940346f3bf8a4d74c19e1f48a00e9.
