Remove the redundant MCFixup::Loc member and instead use MCExpr::Loc to
determine the location for fixups. Previously, many target MCCodeEmitter would
use the beginning of an instruction for fixup locations, which often
resulted in inaccurate column information.
```
// RISCVMCCodeEmitter::getImmOpValue
Fixups.push_back(MCFixup::create(0, Expr, FixupKind, MI.getLoc()));
// X86MCCodeEmitter::emitImmediate
Fixups.push_back(MCFixup::create(static_cast<uint32_t>(CB.size() - StartByte), Expr, FixupKind, Loc));
```
While MCExpr::Loc generally provides more meaningful location data,
tests should avoid over-relying on it. For instance, MCBinaryExpr's
location refers to its operator, and for operands with sigils (like
`$foo`), the location often omits the sigils.
https://llvm-compile-time-tracker.com/compare.php?from=8740ff822d462844506134bb7c425e1778518b95&to=831a11f75d22d64982b13dba132d656ac8567612&stat=instructions%3Au
I've also considered removing MCExpr::Loc (revert
https://reviews.llvm.org/D28861), but we'd lose too much information.
It's also difficult to carry location information to improve location
tracking in target MCCodeEmitter.
This change utilizes previous MCExpr::Loc improvement like
7e3e2e1b8c6ff21e68782a56164139cca334fcf3
7b517cf743f112f980cf6a4d6e6190c2a5b3e451
so that subclasses can provide the appropriate MCAsmInfo to print
MCExpr objects.
At present, llvm/utils/TableGen/AsmMatcherEmitter.cpp constucts a
generic MCAsmInfo.
MCExpr::print has an optional MCAsmInfo argument, which is error-prone
when omitted. MCExpr::print and the convenience helper operator<< are
discouraged to use. Switch to MCAsmInfo::printExpr instead. Use the
target-specific MCAsmInfo if available.
## 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
Use MCSpecifierExpr directly and remove the ARMMCExpr subclass. Define
printImpl and evaluateAsRelocationImpl within ARM*MCAsmInfo classes.
While there is some duplication, it enables better separation for
object file formats.
Prepare for removing ARMMCExpr. Adopt the new naming convention (S_
instead of VK_; the relocation specifier was previously named
`VariantKind`)) used by most other targets.
Make ARMMCAsmInfo.h include ARMMCExpr.h and change .cpp files to include
ARMMCAsmInfo.h. We will eventually remove ARMMCExpr.h.
The code in `ARMAsmParser::parseDirectiveReq` passes both
`parseRegister(Reg, SRegLoc, ERegLoc)` and `SRegLoc` as arguments to
`check()`. Since function arguments are indeterminately sequenced per
C++17 [expr.call]/5, a compiler can evaluate `SRegLoc` before
`parseRegister()` executes. This means `check()` receives a null
location instead of the actual parsed source location for error
reporting.
The fix separates the calls to establish explicit sequencing, ensuring
`check()` receives the correct source location.
This issue was detected by [the CFamily analyzer for
SonarQube](https://www.sonarsource.com/knowledge/languages/cpp/). I'm
happy to provide any additional information or clarification as needed.
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
The .syntax unified directive and .codeX/.code X directives are, other
than some simple common printing code, exclusively implemented in the
targets themselves. Thus, remove the corresponding MCAF_* flags and
reimplement the directives solely within the targets. This avoids
exposing all targets to all other targets' flags.
Since MCAF_SubsectionsViaSymbols is all that remains, convert it to its
own function like other directives, simplifying its implementation.
Note that, on X86, we now always need a target streamer when parsing
assembly, as it's now used for directives that aren't COFF-specific. It
still does not however need to do anything when producing a non-COFF
object file, so this commit does not introduce any new target streamers.
There is some churn in test output, and corresponding UTC regex changes,
due to comments no longer being flushed by these various directives (and
EmitEOL is not exposed outside MCAsmStreamer.cpp so we couldn't do so
even if we wanted to), but that was a bit odd to be doing anyway.
This is motivated by Morello LLVM, which adds yet another assembler flag
to distinguish A64 and C64 instruction sets, but did not update every
switch and so emits warnings during the build. Rather than fix those
warnings it seems better to instead make the problem not exist in the
first place via this change.
`+simd` and `+nosimd` are used to enable or disable NEON Instructions
when compiling for ARM Targets. However, up until now, using these
has not been possible. To enable this, these options are mapped to the
relevant LLVM backend option (`+neon` and `-neon`) so it can be both
enabled and disabled successfully by the user.
Tests have been added to ensure this behaviour is maintained in the
future, along with updates to existing tests as behaviour has now changed
relating to the use of `+simd` and `+nosimd`.
As `simd` has been mapped within the ARMTargetParser.def, support for
this extension is also added for the `--print-support-extensions` command
when the target is AArch32. This will print the `simd` option, along with the
description that relates to the Neon feature. This previously was not
possible as `simd` did not have a related Feature or Negative Feature.
To make this functional as intended, MVE and MVE.FP now rely on their
own Enum identifier, rather than `AEK_SIMD`. While SIMD does refer to
both Neon and Helium technologies, in terms of command line options,
SIMD relates to Neon. Helium relates to MVE and MVE.FP. The Enum
now reflects this too.
Similar to previous migration done for other targets (PowerPC, X86,
etc).
Note: ARMELFObjectWriter::needsRelocateWithSymbol is conservative and
already includes most specifiers.
Follow the X86, Mips, and RISCV renaming.
> "Relocation modifier" suggests adjustments happen during the linker's relocation step rather than the assembler's expression evaluation.
> "Relocation specifier" is clear, aligns with Arm and IBM AIX's documentation, and fits the assembler's role seamlessly.
In addition, rename *MCExpr::getKind, which confusingly shadows the base class getKind.
The StringRef overload is often error-prone as users might forget to
register the MCSymbol.
Add comments to MCTargetExpr and MCSymbolRefExpr::VariantKind.
In the distant future the VariantKind parameter might be removed.
Follow-up to 14951a5a3120e50084b3c5fb217e2d47992a24d1
* Unify getVariantKindName and getVariantKindForName
* Allow each target to specify the preferred case (albeit ignored in MCParser)
Note: targets that use variant kinds should call MCExpr::print with a
non-null MAI to print variant kinds. operator<< passes a nullptr to
`MCExpr::print`, which should be avoided (e.g. Hexagon; fixed in
commit cf00ac81ac049cddb80aec1d6d88b8fab4f209e8).
MCStreamer should not declare arch-specific functions. Such functions
should go to MCTargetStreamer.
Move MCMachOStreamer::emitThumbFunc to ARMTargetMachOStreamer, which is
a new subclass of ARMTargetStreamer. (The new class is just placed in
ARMMachObjectWriter.cpp. The conventional split like
ARMELFObjectWriter.cpp/ARMELFObjectWriter.cpp is overkill.)
`emitCFILabel`, called by ARMWinCOFFStreamer.cpp, has to be made public.
Pull Request: https://github.com/llvm/llvm-project/pull/126199
These instructions only have one register field in their encoding, so
both registers in the assembly must be the same.
Previously, we were accepting these instructions, but ignoring the
second register operand.
Fixes#126227
These operand parser functions for barrier instructions were returning
ParseStatus::Failure for unexpected token kinds, but not outputting an
error message, so these instructions with invalid operands were being
rejected without an error being printed.
Fixes#67949
`t2{LDR,STR}{*}_{PRE,POST}_imm` is pseudo instruction and is expected to
be `t2{LDR,STR}{*}_{PRE,POST}`. During building the new MCInst of
`t2{LDR,STR}{*}_{PRE,POST}`, the order of operands looks incorrect.
Fixes https://github.com/llvm/llvm-project/issues/97020.
---------
Co-authored-by: Kai Luo <luokai@vivo.com>
If the assembler sees this instruction, understanding `foo` to be an
external symbol, there's no relocation it can write that will put the
whole value of `foo` into the 8-bit immediate field of the 16-bit Thumb
add instruction. So it should report an error message pointing at the
source line, and in LLVM 18, it did exactly that. But now the error is
not reported, due to an indexing error in the operand list in
`validateInstruction`, and instead the code continues to attempt
assembly, ending up aborting at the `llvm_unreachable` at the end of
`getHiLoImmOpValue`.
In this commit I've fixed the index in the `ARM::tMOVi8` case of
`validateInstruction`, and also the one for `tADDi8` which must cope
with either the 2- or 3-operand form in the input assembly source. But
also, while writing the test, I found that if you assemble for Armv7-M
instead of Armv6-M, the instruction has opcode `t2ADDri` when it goes
through `validateInstruction`, and only turns into `tMOVi8` later in
`processInstruction`. Then it's too late for `validateInstruction` to
report that error. So I've adjusted `processInstruction` to spot that
case and inhibit the conversion.
The register list in vscclrm is unusual in three ways:
* The encoded size can be zero, meaning the list contains only vpr.
* Double-precision registers past d15 are permitted even when the
subtarget doesn't have them, they are instead ignored when the
instruction executes.
* The single-precision variant allows double-precision registers d16
onwards, which are encoded as a pair of single-precision registers.
Fixing this also incidentally changes a vlldm/vlstm error message: when
the first register is in the range d16-d31 we now get the "operand must
be exactly..." error instead of "register expected".
This fixes all the places that hit the new assertion added in
https://github.com/llvm/llvm-project/pull/106524 in tests. That is,
cases where the value passed to the APInt constructor is not an N-bit
signed/unsigned integer, where N is the bit width and signedness is
determined by the isSigned flag.
The fixes either set the correct value for isSigned, set the
implicitTrunc flag, or perform more calculations inside APInt.
Note that the assertion is currently still disabled by default, so this
patch is mostly NFC.
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.
S.substr(N) is simpler than S.slice(N, StringRef::npos) and
S.slice(N, S.size()). Also, substr is probably better recognizable
than slice thanks to std::string_view::substr.
This was broken by https://github.com/llvm/llvm-project/pull/83436 as in
optional operands meant when the CC operand is provided the
`parsePKHImm` parser is applied to register operands, which previously
erroneously produced an error.
