| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
relocation types
Simplify code, which is enabled by
40789ce7f1b7cff6de82b7f93db25a8c54194d46 ("MCFixup: Move relocation values before FK_NONE")
|
|
... to align with other targets, e.g., https://reviews.llvm.org/D77853
(AArch64) and https://reviews.llvm.org/D83634 (AVR).
binutils's sparc port uses %d when imm<=9, diverging from other ports.
We do not follow the binutils sparc port behavior.
|
|
atomic_load_nonext_8/16/32/64. NFC (#137428)
This makes them more consistent with the checks performed by regular loads. We can't simply add IsNonExtLoad to the existing atomic_load_8/16/32/64 as that would affect out of tree targets.
|
|
CTTZ can be implemented in terms of CTLZ, for which there's a native
instruction in VIS3.
Promote i32 CTTZ in that case so that the native instruction gets used.
Reviewers: rorth, brad0, s-barannikov
Reviewed By: s-barannikov
Pull Request: https://github.com/llvm/llvm-project/pull/135894
|
|
atomic_load_*ext_8/atomic_load_*ext_16 where possible. (#137279)
isAnyExtLoad/isZExtLoad/isSignExtLoad are able to emit predicate checks
from tablegen now so we should use them.
The next step would be to add isNonExtLoad versions and migrate all
remaining uses of atomic_load_8/16/32/64 to that.
|
|
have VIS3" (#135897) (#136475)
Update the tests to reflect the change in instruction ordering.
Otherwise there are no changes from the previous commit.
This reverts commit 5e9650ec2deb2f2bb6d5ad28e83bb6cd3c4189e4.
|
|
We will increase the use of raw relocation types and eliminate fixup
kinds that correspond to relocation types. The getFixupKindInfo
functions will return an rvalue instead. Let's update the return type
from a const reference to a value type.
|
|
Add two helper functions to simplify checks for relocation types,
replacing direct comparisons with FirstRelocationKind and
FirstLiteralRelocationKind. Note: Some targets haven't utilized
isRelocation yet.
Also, update RelaxFixupKind to use 0 as the sentinel value.
|
|
Reviewers: brad0, s-barannikov, rorth
Reviewed By: s-barannikov
Pull Request: https://github.com/llvm/llvm-project/pull/135716
|
|
Reviewers: s-barannikov, brad0, rorth
Reviewed By: s-barannikov
Pull Request: https://github.com/llvm/llvm-project/pull/135715
|
|
Also, guard emission by `needsFrameMoves()` check. There are no changes
in tests because cfi instructions are currently ignored by AsmPrinter
when they don't need to be printed/encoded.
PR: https://github.com/llvm/llvm-project/pull/136027
|
|
VIS3" (#135897)
This change breaks multiply tests on SPARC.
https://lab.llvm.org/buildbot/#/builders/108/builds/11691/steps/6/logs/FAIL__LLVM__multiply-extension_ll
Reverts llvm/llvm-project#135714
|
|
Reviewers: s-barannikov, rorth, brad0
Reviewed By: s-barannikov
Pull Request: https://github.com/llvm/llvm-project/pull/135714
|
|
Reviewers: brad0, s-barannikov, rorth
Reviewed By: s-barannikov
Pull Request: https://github.com/llvm/llvm-project/pull/135713
|
|
Reviewers: rorth, brad0, s-barannikov
Reviewed By: s-barannikov
Pull Request: https://github.com/llvm/llvm-project/pull/135712
|
|
Move `Fixup.getKind() >= FirstLiteralRelocationKind` from target hooks
to ELFObjectWriter::recordRelocation.
Currently, getRelocType cannot be skipped for LoongArch due to #135519
|
|
|
|
We will replace the MCSymbolRefExpr member in MCValue with MCSymbol.
This change reduces dependence on MCSymbolRefExpr.
|
|
We will replace the MCSymbolRefExpr member in MCValue with MCSymbol.
This change reduces dependence on MCSymbolRefExpr.
|
|
Also fix up any mistakes/typos in instruction definitions.
Reviewers: rorth, s-barannikov, brad0, MaskRay
Reviewed By: s-barannikov
Pull Request: https://github.com/llvm/llvm-project/pull/130967
|
|
This primarily simplifies backend evaluateAsRelocatableImpl.
|
|
Reviewers: brad0, s-barannikov, rorth
Reviewed By: s-barannikov
Pull Request: https://github.com/llvm/llvm-project/pull/130966
|
|
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.
|
|
|
|
This removes the extra argument from commit 814b34f31e163e76b816194004689985f5b9fd7b.
Also remove unneeded `>= FirstLiteralRelocationKind`.
|
|
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.
|
|
Follow-up to d6fbffa23c84e622735b3e880fd800985c1c0072 . This commit
updates all call sites and removes the argument from the function.
|
|
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.
|
|
MCRegister. (#128473)
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.
|
|
|
|
Implement `setsw` pseudoinstruction for setting a 32-bit signed imm.
Reviewers: brad0, s-barannikov, rorth
Reviewed By: s-barannikov
Pull Request: https://github.com/llvm/llvm-project/pull/125150
|
|
Reviewers: s-barannikov, brad0, rorth
Reviewed By: s-barannikov
Pull Request: https://github.com/llvm/llvm-project/pull/125149
|
|
Follow up to https://github.com/llvm/llvm-project/issues/123569
|
|
(NFC) (#120622)
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.
|
|
(#117525)
…on returning { i8, i128 }
Fixes https://github.com/llvm/llvm-project/issues/96432.
|
|
This commit changes the branch emission logic so that instead of
throwing the "branch target out of range" error, we emit a relocation
instead.
|
|
This follows GCC behavior of allowing a trailing immediate, that is
ignored by the assembler.
|
|
(#117375)
This removes operands/results either in SDNode description or in ISel
code so that they match each other.
|
|
This avoids assertion failures once we disable implicit
truncation in getConstant().
|
|
Identified with misc-include-cleaner.
|
|
TC_RETURN nodes do not have a glue result.
|
|
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
|
|
The value returned from the function depends only on the instruction opcode.
As a drive-by, change the type of the argument to const-reference.
|
|
This patch fixes:
llvm/lib/Target/Sparc/SparcFrameLowering.cpp:226:29: error: unused
variable 'RegInfo' [-Werror,-Wunused-variable]
|
|
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.
|
|
Similar to printInst. printRegName may change states (e.g. #113834).
|
|
`TargetFrameLowering::hasFP()` (#106014)
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>
|
|
Align i128s to 16 bytes, following the example at
https://reviews.llvm.org/D86310.
clang already does this implicitly, but do it in backend code too for
the benefit of other frontends (see e.g
https://github.com/llvm/llvm-project/issues/102783 &
https://github.com/rust-lang/rust/issues/128950).
|
|
Update function names to adhere to LLVM coding standard.
|
