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.
Target shouldForceRelocation checks `FirstLiteralRelocationKind` to
determine whether a relocation is forced due to the .reloc directive. We
should move the code to evaluateFixup so that many targets don't need to
override shouldForceRelocation.
fixELFSymbolsInTLSFixups walks the expression tree, which is complex and
unnecessary. As the expression must be relocatable, we can move the code
to getRelocType and just set SymA. The behavior is similar to GNU
assembler.
__tls_get_addr registery (https://reviews.llvm.org/D43271) is unnecessary
now. SparcMCExpr::visitUsedExpr registers the symbol.
NVPTX, SPIRV, and WebAssembly pass virtual registers to this function
since they don't perform register allocation. We need to use Register to
avoid a virtual register being converted to MCRegister by the caller.
This patch is in preparation to enable setting the MachineInstr::MIFlag
flags, i.e. FrameSetup/FrameDestroy, on callee saved register
spill/reload instructions in prologue/epilogue. This eventually helps in
setting the prologue_end and epilogue_begin markers more accurately.
The DWARF Spec in "6.4 Call Frame Information" says:
The code that allocates space on the call frame stack and performs the
save
operation is called the subroutine’s prologue, and the code that
performs
the restore operation and deallocates the frame is called its epilogue.
which means the callee saved register spills and reloads are part of
prologue (a.k.a frame setup) and epilogue (a.k.a frame destruction),
respectively. And, IIUC, LLVM backend uses FrameSetup/FrameDestroy flags
to identify instructions that are part of call frame setup and
destruction.
In the trunk, while most targets consistently set
FrameSetup/FrameDestroy on save/restore call frame information (CFI)
instructions of callee saved registers, they do not consistently set
those flags on the actual callee saved register spill/reload
instructions.
I believe this patch provides a clean mechanism to set
FrameSetup/FrameDestroy flags on the actual callee saved register
spill/reload instructions as needed. And, by having default argument of
MachineInstr::NoFlags for Flags, this patch is a NFC.
With this patch, the targets have to just pass FrameSetup/FrameDestroy
flag to the storeRegToStackSlot/loadRegFromStackSlot calls from the
target derived spillCalleeSavedRegisters and restoreCalleeSavedRegisters
to set those flags on callee saved register spill/reload instructions.
Also, this patch makes it very easy to set the source line information
on callee saved register spill/reload instructions which is needed by
the DwarfDebug.cpp implementation to set prologue_end and epilogue_begin
markers more accurately.
As per DwarfDebug.cpp implementation:
prologue_end is the first known non-DBG_VALUE and non-FrameSetup
location
that marks the beginning of the function body
epilogue_begin is the first FrameDestroy location that has been seen in
the
epilogue basic block
With this patch, the targets have to just do the following to set the
source line information on callee saved register spill/reload
instructions, without hampering the LLVM's efforts to avoid adding
source line information on the artificial code generated by the
compiler.
<Foo>InstrInfo::storeRegToStackSlot() {
...
DebugLoc DL =
Flags & MachineInstr::FrameSetup ? DebugLoc() : MBB.findDebugLoc(I);
...
}
<Foo>InstrInfo::loadRegFromStackSlot() {
...
DebugLoc DL =
Flags & MachineInstr::FrameDestroy ? MBB.findDebugLoc(I) : DebugLoc();
...
}
While I understand this patch would break out-of-tree backend builds, I
think it is in the right direction.
One immediate use case that can benefit from this patch is fixing
#120553 becomes simpler.
Following discussions in #110443, and the following earlier discussions
in https://lists.llvm.org/pipermail/llvm-dev/2017-October/117907.html,
https://reviews.llvm.org/D38482, https://reviews.llvm.org/D38489, this
PR attempts to overhaul the `TargetMachine` and `LLVMTargetMachine`
interface classes. More specifically:
1. Makes `TargetMachine` the only class implemented under
`TargetMachine.h` in the `Target` library.
2. `TargetMachine` contains target-specific interface functions that
relate to IR/CodeGen/MC constructs, whereas before (at least on paper)
it was supposed to have only IR/MC constructs. Any Target that doesn't
want to use the independent code generator simply does not implement
them, and returns either `false` or `nullptr`.
3. Renames `LLVMTargetMachine` to `CodeGenCommonTMImpl`. This renaming
aims to make the purpose of `LLVMTargetMachine` clearer. Its interface
was moved under the CodeGen library, to further emphasis its usage in
Targets that use CodeGen directly.
4. Makes `TargetMachine` the only interface used across LLVM and its
projects. With these changes, `CodeGenCommonTMImpl` is simply a set of
shared function implementations of `TargetMachine`, and CodeGen users
don't need to static cast to `LLVMTargetMachine` every time they need a
CodeGen-specific feature of the `TargetMachine`.
5. More importantly, does not change any requirements regarding library
linking.
cc @arsenm @aeubanks
SPARC ABI doesn't use stack realignment, so let LLVM know about it in
`SparcFrameLowering`. This has the side effect of making all overaligned
allocations go through `LowerDYNAMIC_STACKALLOC`, so implement the
missing logic there too for overaligned allocations.
This makes the SPARC backend not crash on overaligned `alloca`s and fix
https://github.com/llvm/llvm-project/issues/89569.
Some targets (e.g. PPC and Hexagon) already did this. I think it's best
to do this consistently so that frontend authors don't run into
inconsistent results when they emit `naked` functions. For example, in
Zig, we had to change our emit code to also set `frame-pointer=none` to
get reliable results across targets.
Note: I don't have commit access.
Add support for using a thread-local variable with a specified offset
for holding the stack guard canary value. This supports both 32- and 64-
bit PowerPC targets.
This mirrors changes from #108942 but targeting PowerPC instead of
RISCV. Because both of these PRs modify the same driver functions, this
series is stack on top of the RISC-V one.
---------
Signed-off-by: Keith Packard <keithp@keithp.com>
The renamable flag is useful during MachineCopyPropagation but renamable
flag will be dropped after lowerCopy in some case.
This patch introduces extra arguments to pass the renamable flag to
copyPhysReg.
This patch adds a pass that provides workarounds for the errata
described in GRLIB-TN-0009, GRLIB-TN-0010, GRLIB-TN-0011, GRLIB-TN-0012,
and GRLIB-TN-0013, that are applicable to the GR712RC and UT700. The
documents are available for download from here:
https://www.gaisler.com/index.php/information/app-tech-notes
The pass will detect certain sensitive instruction sequences and prevent
them from occurring by inserting NOP instruction. Below is an overview
of each of the workarounds. A similar implementation is available in
GCC.
GRLIB-TN-0009:
* Insert NOPs to prevent the sequence (stb/sth/st/stf) -> (single
non-store/load instruction) -> (any store)
* Insert NOPs to prevent the sequence (std/stdf) -> (any store)
GRLIB-TN-0010:
* Insert a NOP between load instruction and atomic instruction (swap and
casa).
* Insert a NOP at branch target if load in delay slot and atomic
instruction at branch target.
* Do not allow functions to begin with atomic instruction.
GRLIB-TN-0011:
* Insert .p2align 4 before atomic instructions (swap and casa).
GRLIB-TN-0012:
* Place a NOP at the branch target of an integer branch if it is a
floating-point operation or a floating-point branch.
GRLIB-TN-0013:
* Prevent (div/sqrt) instructions in the delay slot.
* Insert NOPs to prevent the sequence (div/sqrt) -> (two or three
floating point operations or loads) -> (div/sqrt).
* Do not insert NOPs if any of the floating point operations have a
dependency on the destination register of the first (div/sqrt).
* Do not insert NOPs if one of the floating point operations is a
(div/sqrt).
* Insert NOPs to prevent (div/sqrt) followed by a branch.
Implement handling for `v8plus` feature bit to allow the user to switch
between V8 and V8+ mode with 32-bit code.
Currently this only sets the appropriate ELF machine type and flags;
codegen changes will be done in future patches.
This is done as a prerequisite for `-mv8plus` flag on clang (#98713).
The parameter is confusing as it duplicates MCStreamer::isVeboseAsm
(initialized from MCTargetOptions::AsmVerbose). After
233cca169237b91d16092c82bd55ee6a283afe98, no in-tree target uses the
parameter.
Well, not quite that simple. We can tc memset since it returns the first
argument but bzero doesn't do that and therefore we can end up
miscompiling.
This patch also refactors the logic out of isInTailCallPosition() into the callers.
As a result memcpy and memmove are also modified to do the same thing
for consistency.
rdar://131419786
Summary:
These Libcalls represent which functions are available to the backend.
If a runtime call is not available, the target sets the the name to
`nullptr`. Currently, this logic is spread around the various targets.
This patch pulls all of the locations that disable libcalls into the
intializer. This patch is effectively NFC.
The motivation behind this patch is that currently the LTO handling uses
the list of all runtime calls to determine which functions cannot be
internalized and must be extracted from static libraries. We do not want
this to happen for libcalls that are not emitted by the backend. A
follow-up patch will move out this logic so the LTO pass can know which
rtlib calls are actually used by the backend.
Validate and reject any unknown or unavailable instruction mnemonics early
in ParseInstruction, before any operand parsing is performed. Some operands
(mainly memory ones) can be parsed slightly differently in V8 and V9
assembly language, so by rejecting unknown or unavailable instructions early
we can prevent the error message from being shadowed by the one raised during
operand parsing.
As a side effect this also allows us to tell unknown and unavailable
mnemonics apart, and issue a suggestion in appropriate cases.
This is based on the approach taken by the MIPS backend.
Reviewers: brad0, rorth, s-barannikov, jrtc27
Reviewed By: s-barannikov
Pull Request: https://github.com/llvm/llvm-project/pull/96021
Emit the correct machine type when writing out ELF objects.
This patch is modeled on GCC's behavior:
- `-m32` emits an object of type EM_SPARC;
- `-m32 -mcpu=v9` emits EM_SPARC32PLUS (however, see below); and
- `-m64` emits EM_SPARCV9.
Note that GCC does not guarantee emission of EM_SPARC32PLUS objects,
since GNU as doesn't support user control of emitted machine type.
It will always autodetect the type based on the instruction mix:
- If there's a V9 instruction inside, then emit EM_SPARC32PLUS; and
- Emit EM_SPARC otherwise.
For LLVM we choose deterministic behavior instead for simplicity.
Unify parts of ASI and Prefetch tag matching at `parseASITag`
and `parsePrefetchTag` to use a common function to parse any immediate
expressions. This introduces a slight regression to error messages,
but is needed so we can enable `ParseForAllFeatures`
in `MatchOperandParserImpl` in a future patch.
Reviewers: jrtc27, brad0, rorth, s-barannikov
Reviewed By: s-barannikov
Pull Request: https://github.com/llvm/llvm-project/pull/96020
This adds the alternate mnemonics for movrz and movrnz.
Reviewers: s-barannikov, jrtc27, brad0, rorth
Reviewed By: s-barannikov
Pull Request: https://github.com/llvm/llvm-project/pull/94252
If the Count passed into writeNopData is not a multiple of four,
add a little amount of zeros before writing the NOP stream.
This makes it match the behavior of GNU binutils.
Reviewers: brad0, rorth, s-barannikov, jrtc27
Reviewed By: s-barannikov
Pull Request: https://github.com/llvm/llvm-project/pull/94251
