The object file format specific derived classes are used in context
where the type is statically known. We don't use isa/dyn_cast and we
want to eliminate MCSymbol::Kind in the base class.
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.
## 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
Many targets define MCTargetExpr subclasses just to encode an expression
with a relocation specifier. Create a generic MCSpecifierExpr to be
inherited instead. Migrate M68k and SPARC as examples.
Follow the X86 and Mips 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’s usage, and fits the assembler's role seamlessly.
In addition, rename *MCExpr::getKind, which confusingly shadows the base class getKind.
Most changes are mechanic, except:
* ELFObjectWriter::shouldRelocateWithSymbol: .TOC.@tocbase does not
register the undefined symbol. Move the handling into the
Sym->isUndefined() code path.
* ELFObjectWriter::fixSymbolsInTLSFixups's VK_PPC* cases are moved to
PPCELFObjectWriter::getRelocType. We should do similar refactoring
for other targets and eventually remove fixSymbolsInTLSFixups.
In the future, we should classify PPCMCExpr similar to AArch64MCExpr.
Make the name conciser. PPC-specific MCSymbolRefExpr::VariantKind
members will be moved to PPCMCExpr and we will not ue
MCSymbolRefExpr::VariantKind's "generic" members, so there won't be
mix-and-match.
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.
This cleans up @l @ha optimization in PPCAsmParser and is also the first
step toward removing VK_PPC_* from the generic MCSymbolRefExpr::VariantKind.
Basically we ensure that @l @ha family modifiers always lead to
PPCMCExpr and avoid MCSymbolRefExpr::VariantKind. This allows us
to delete a lot of switch statements that involve a long list of VK_PPC_LO/VK_PPC_HI/...
52cf8e44880bcf614068b66b63393aa8da1edd76 (2013) introduced the
VK_PPC_TLSGD workaround to prevent unconditional reference to
_GLOBAL_OFFSET_TABLE_ in ELFObjectWriter.
e2b355d651ed8f2cbe61672c4c39b6419e471265 (2015) removed the
`_GLOBAL_OFFSET_TABLE_` hack for the generic VK_TLSGD,
making the VK_PPC_TLSGD workaround unneeded.
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).
Lowercase the name before calling MatchRegisterName(), to restore
support for using `%R3` instead of `%r3` and similar, matching the GNU
assembler.
Fixes https://github.com/llvm/llvm-project/issues/126786.
Commit 93589057830b2c3c35500ee8cac25c717a1e98f9 was reverted because it
caused a failure with test `lld :: ELF/ppc64-local-exec-tls.s`. This
relands the commit with a fix for the test.
If an instruction doesn't support memory operands, but one is provided,
an error should be raised. And conversely, if an instruction requires a
memory operand, but none is given, an error should be raised.
Initial patch to start using TableGen's auto generated function
`MatchRegisterName()`.
Update `PPCAsmParser::matchRegisterName()` implementation to align more
with tablegen's auto generated function.
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 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 patch adds the majority of the missing extended mnemonics that were
introduced in Power 10.
The only extended mnemonics that were not added are related to the plq
and pstq instructions. These will be added in a separate patch as the
instructions themselves would also have to be added.
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).
PPC32 -fpic/-fPIC generates `bl __tls_get_addr(x@tlsgd)@PLT` or
`bl __tls_get_addr(x@tlsgd)@PLT+32768`.
`powerpc-linux-gnu-gcc -fPIC` generates `bl __tls_get_addr+32668(x@tlsgd)@plt`.
These expressions can be parsed by GNU assembler but not by the integrated
assembler. Add the support.
Differential Revision: https://reviews.llvm.org/D153206
This patch migrates uses of StringRef::{starts,ends}with_insensitive
to StringRef::{starts,ends}_with_insensitive so that we can use names
similar to those used in std::string_view. I'm planning to deprecate
StringRef::{starts,ends}with_insensitive once the migration is
complete across the code base.
Differential Revision: https://reviews.llvm.org/D150426
Add the following Decimal Floating Point (DFP) instructions for PowerPC.
dadd, daddq, dsub, dsubq
In order to add these instructions a new register class for a pair
of floating point registers is added.
This patch is only to allow the user to specify the instructions in
assembly. There is no scheduling or patterns for the instructions.
Reviewed By: amyk
Differential Revision: https://reviews.llvm.org/D148597
A new register class as well as a number of related subregisters are being added
to Future CPU. These registers are Dense Math Registers (DMR) and are 1024 bits
long. These regsiters can also be used in consecutive pairs which leads to a
register that is 2048 bits.
This patch also adds 7 new instructions that use these registers. More
instructions will be added in future patches.
Reviewed By: amyk, saghir
Differential Revision: https://reviews.llvm.org/D136366
The Linux kernel build uses absolute expressions suffixed with @lo/@ha
relocations. This currently doesn't work for DS/DQ form instructions and
there is no reason for it not to. It also works with GAS.
This patch allows this as long as the value is a multiple of 4/16
for DS/DQ form.
Differential revision: https://reviews.llvm.org/D115419
This patch is the first step to enable support of GNU attribute in LLVM
PowerPC, enabling it for PowerPC targets, otherwise llvm-mc raises error
when seeing the attribute section.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D115854
