summaryrefslogtreecommitdiff
path: root/llvm/lib/Target/SystemZ/SystemZInstrInfo.cpp
AgeCommit message (Collapse)Author
2025-11-10CodeGen: Remove TRI arguments from stack load/store hooks (#158240)Matt Arsenault
This is directly available in TargetInstrInfo
2025-11-10CodeGen: Keep reference to TargetRegisterInfo in TargetInstrInfo (#158224)Matt Arsenault
Both conceptually belong to the same subtarget, so it should not be necessary to pass in the context TargetRegisterInfo to any TargetInstrInfo member. Add this reference so those superfluous arguments can be removed. Most targets placed their TargetRegisterInfo as a member in TargetInstrInfo. A few had this owned by the TargetSubtargetInfo, so unify all targets to look the same.
2025-09-08CodeGen: Pass SubtargetInfo to TargetGenInstrInfo constructors (#157337)Matt Arsenault
This will make it possible for tablegen to make subtarget dependent decisions without adding new arguments to every target. --------- Co-authored-by: Sergei Barannikov <barannikov88@gmail.com>
2025-08-04[Target] Remove unnecessary casts (NFC) (#151902)Kazu Hirata
getImm() already returns int64_t.
2025-04-16[SystemZ] Fix warningsKazu Hirata
This patch fixes: llvm/lib/Target/SystemZ/SystemZISelLowering.cpp:6916:7: error: unused variable 'RegVT' [-Werror,-Wunused-variable] llvm/lib/Target/SystemZ/SystemZInstrInfo.cpp:1265:30: error: unused variable 'RC' [-Werror,-Wunused-variable]
2025-04-16[SystemZ] Add support for 16-bit floating point. (#109164)Jonas Paulsson
- _Float16 is now accepted by Clang. - The half IR type is fully handled by the backend. - These values are passed in FP registers and converted to/from float around each operation. - Compiler-rt conversion functions are now built for s390x including the missing extendhfdf2 which was added. Fixes #50374
2025-03-28[SystemZ] Remove custom implementation of optimizeLoadInst [NFC] (#133123)Philip Reames
In 236f938ef, I introduced a generic version of this routine. I believe that the SystemZ specific version of this is less general than the generic version, and is thus unrequired. I wasn't 100% given the difference in sub-register, multiple use and defs, but from the SystemZ code, it looks like those cases simply don't arise?
2025-03-25[SystemZ] Add `is(LoadFrom|StoreTo)StackSlotPostFE` to SystemZBackend (#132928)Dominik Steenken
As part of an effort to enable instr-ref-based debug value tracking, this PR implements `SystemZInstrInfo::isLoadFromStackSlotPostFE`, as well as `SystemZInstrInfo::isStoreToStackSlotPostFE`. The implementation relies upon the presence of MachineMemoryOperands on the relevant `MachineInstr`s in order to access the `FrameIndex` post frame index elimination. Since these new functions are only meant to be called after frame-index elimination, they assert against the present of a frame index on the base register operand of the instruction. Outside of the utility of these functions to enable instr-ref-based debug value tracking, they also changes the behavior of the AsmPrinter, since it will now be able to properly detect non-folded spills and reloads, so this changes a number of tests that were checking specifically for folded reloads. Note that there are some tests that still check for `vst` and `vl` as folded spills/reloads even though they should be straight reloads. This will be addressed in a future PR. Co-authored-by: Dominik Steenken <dominik.steenken@gmail.com>
2025-03-25[SystemZ] Implement basic `isCopyInstrImpl` (#132903)Dominik Steenken
As a first step toward implementing SystemZ support for instr-ref-based debug info tracking, this commit adds a basic implementation for the previously absent `SystemZInstrInfo::isCopyInstrImpl`. This is accomplished by adding a new flag called `isMoveReg` on the relevant instructions and calling upon that bit of information to implement the function. Which instructions to add the flag to was based on the implementation of `SystemZInstrInfo::copyPhysReg`. The full list of instructions is as follows: #### General-Purpose Registers - `lr` - `lgr` #### Floating Point Registers - `ler` - `ldr` - `lxr` #### Vector Registers - `vlr`
2025-02-24[CodeGen] Change copyPhysReg interface to use Register instead of ↵Craig Topper
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.
2025-01-30SystemZ: Handle copies between gr64 and fp64 (#124890)Matt Arsenault
I'm guessing based on tablegen definitions. I also don't really understand how this could have been missing. This defends against regressions in a future peephole-opt patch.
2025-01-22[llvm] Pass MachineInstr flags to storeRegToStackSlot/loadRegFromStackSlot ↵Venkata Ramanaiah Nalamothu
(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.
2024-11-05[SystemZ][XRay] Implement XRay instrumentation for SystemZ (#113253)Kai Nacke
Expands pseudo instructions PATCHABLE_FUNCTION_ENTER and PATCHABLE_RET into a small instruction sequence which calls into the XRay library.
2024-08-27[TII][RISCV] Add renamable bit to copyPhysReg (#91179)Piyou Chen
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.
2024-07-26[CodeGen] Remove AA parameter of isSafeToMove (#100691)Pengcheng Wang
This `AA` parameter is not used and for most uses they just pass a nullptr. The use of `AA` was removed since 8d0383e.
2024-05-15[SystemZ] Handle address clobbering in splitMove(). (#92105)Jonas Paulsson
When expanding an L128 (which is used to reload i128) it is possible that the quadword destination register clobbers an address register. This patch adds an assertion against the case where both of the expanded parts clobber the address, and in the case where one of the expanded parts do so puts it last. Fixes #91437
2024-05-06Reapply "SystemZ: Fold copy of vector immediate to gr128" (#91099)Matt Arsenault
This reverts commit a415b4dfcc02e3e82b8c8a7836f7c04b9d65dc9b. Modify the instruction in place to transform it into a REG_SEQUENCE, which is what other implementations of foldImmediate do. Also start erasing the def instruction if there are no other uses. Fixes #91110.
2024-05-04Revert "SystemZ: Fold copy of vector immediate to gr128" (#91099)Vitaly Buka
Fails here: https://lab.llvm.org/buildbot/#/builders/239/builds/6893 https://lab.llvm.org/buildbot/#/builders/5/builds/43113 https://lab.llvm.org/buildbot/#/builders/168/builds/20228 Reverts llvm/llvm-project#90706
2024-05-04Add clarifying parenthesis around non-trivial conditions in ternary ↵luolent
expressions. (#90391) Fixes [#85868](https://github.com/llvm/llvm-project/issues/85868) Parenthesis are added as requested on ternary operators with non trivial conditions. I used this [precedence table](https://en.cppreference.com/w/cpp/language/operator_precedence) for reference, to make sure we get the expected behavior on each change.
2024-05-03SystemZ: Fold copy of vector immediate to gr128 (#90706)Matt Arsenault
If materializing a constant in a vector register that is just going to be copied to general registers, directly materialize the immediate in the gpr. This will avoid a few lit test regressions in a future commit.
2024-05-02SystemZ: Handle gr128 to fp128 copies in copyPhysReg (#90861)Matt Arsenault
2024-04-30SystemZ: Implement copyPhysReg between vr128 and gr128 (#90616)Matt Arsenault
I have no idea if this is correct and I probably swapped the element ordering somewhere.
2024-04-30[SystemZ] Enable MachineCombiner for FP reassociation (#83546)Jonas Paulsson
Enable MachineCombining for FP add, sub and mul. In order for this to work, the default instruction selection of reg/mem opcodes is disabled for ISD nodes that carry the flags that allow reassociation. The reg/mem folding is instead done after MachineCombiner by PeepholeOptimizer. SystemZInstrInfo optimizeLoadInstr() and foldMemoryOperandImpl() ("LoadMI version") have been implemented for this purpose also by this patch.
2024-04-24[CodeGen] Make the parameter TRI required in some functions. (#85968)Xu Zhang
Fixes #82659 There are some functions, such as `findRegisterDefOperandIdx` and `findRegisterDefOperand`, that have too many default parameters. As a result, we have encountered some issues due to the lack of TRI parameters, as shown in issue #82411. Following @RKSimon 's suggestion, this patch refactors 9 functions, including `{reads, kills, defines, modifies}Register`, `registerDefIsDead`, and `findRegister{UseOperandIdx, UseOperand, DefOperandIdx, DefOperand}`, adjusting the order of the TRI parameter and making it required. In addition, all the places that call these functions have also been updated correctly to ensure no additional impact. After this, the caller of these functions should explicitly know whether to pass the `TargetRegisterInfo` or just a `nullptr`.
2024-03-28[SystemZ] Eliminate call sequence instructions early. (#77812)Jonas Paulsson
On SystemZ, the outgoing argument area which is big enough for all calls in the function is created once during the prolog, as opposed to adjusting the stack around each call. The call-sequence instructions are therefore not really useful any more than to compute the maximum call frame size, which has so far been done by PEI, but can just as well be done at an earlier point. This patch removes the mapping of the CallFrameSetupOpcode and CallFrameDestroyOpcode and instead computes the MaxCallFrameSize directly after instruction selection and then removes the ADJCALLSTACK pseudos. This removes the confusing pseudos and also avoids the problem of having to keep the call frame size accurate when creating new MBBs. This fixes #76618 which exposed the need to maintain the call frame size when splitting blocks (which was not done).
2024-03-17[CodeGen] Use LocationSize for MMO getSize (#84751)David Green
This is part of #70452 that changes the type used for the external interface of MMO to LocationSize as opposed to uint64_t. This means the constructors take LocationSize, and convert ~UINT64_C(0) to LocationSize::beforeOrAfter(). The getSize methods return a LocationSize. This allows us to be more precise with unknown sizes, not accidentally treating them as unsigned values, and in the future should allow us to add proper scalable vector support but none of that is included in this patch. It should mostly be an NFC. Global ISel is still expected to use the underlying LLT as it needs, and are not expected to see unknown sizes for generic operations. Most of the changes are hopefully fairly mechanical, adding a lot of getValue() calls and protecting them with hasValue() where needed.
2024-03-08Reapply "Convert many LivePhysRegs uses to LiveRegUnits" (#84338)AtariDreams
This only converts the instances where all that is needed is to change the variable type name. Basically, anything that involves a function that LiveRegUnits does not directly have was skipped to play it safe. Reverts https://github.com/llvm/llvm-project/commit/7a0e222a17058a311b69153d0b6f1b4459414778
2024-03-07Revert "Convert many LivePhysRegs uses to LiveRegUnits (#83905)"Jay Foad
This reverts commit 2a13422b8bcee449405e3ebff957b4020805f91c. It was causing test failures on the expensive check builders.
2024-03-06Convert many LivePhysRegs uses to LiveRegUnits (#83905)AtariDreams
2024-02-01[TTI] Use Register in isLoadFromStackSlot and isStoreToStackSlot [nfc] (#80339)Philip Reames
2024-01-26[NFC] Rename TargetInstrInfo::FoldImmediate to ↵Shengchen Kan
TargetInstrInfo::foldImmediate and simplify implementation for X86
2024-01-15[SystemZ] Don't use FP Load and Test as comparisons to same reg (#78074)Jonas Paulsson
The usage of FP Load and Test instructions as a comparison against zero with the assumption that the dest reg will always reflect the source reg is actually incorrect: Unfortunately, a SNaN will be converted to a QNaN, so the instruction may actually change the value as opposed to being a pure register move with a test. This patch - changes instruction selection to always emit FP LT with a scratch def reg, which will typically be allocated to the same reg if dead. - Removes the conversions into FP LT in SystemZElimcompare.
2023-06-16[MC] Use regunits instead of MCRegUnitIterator. NFC.Jay Foad
Differential Revision: https://reviews.llvm.org/D153122
2023-01-23[SystemZ] Use isShiftedMask_64 instead of isStringOfOnes (NFC)Kazu Hirata
isStringOfOnes does the same thing as isShiftedMask_64, provided that the parameter is nonzero, which is the case for both calls in this patch.
2023-01-23[MC] Make more use of MCInstrDesc::operands. NFC.Jay Foad
Change MCInstrDesc::operands to return an ArrayRef so we can easily use it everywhere instead of the (IMHO ugly) opInfo_begin and opInfo_end. A future patch will remove opInfo_begin and opInfo_end. Also use it instead of raw access to the OpInfo pointer. A future patch will remove this pointer. Differential Revision: https://reviews.llvm.org/D142213
2023-01-13[CodeGen][Target] Remove uses of ↵Craig Topper
Register::isPhysicalRegister/isVirtualRegister. NFC Use isPhysical/isVirtual methods.
2022-12-17[CodeGen] Additional Register argument to ↵Christudasan Devadasan
storeRegToStackSlot/loadRegFromStackSlot With D134950, targets get notified when a virtual register is created and/or cloned. Targets can do the needful with the delegate callback. AMDGPU propagates the virtual register flags maintained in the target file itself. They are useful to identify a certain type of machine operands while inserting spill stores and reloads. Since RegAllocFast spills the physical register itself, there is no way its virtual register can be mapped back to retrieve the flags. It can be solved by passing the virtual register as an additional argument. This argument has no use when the spill interfaces are called during the greedy allocator or even the PrologEpilogInserter and can pass a null register in such cases. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D138656
2022-08-28[llvm] Use range-based for loops (NFC)Kazu Hirata
2022-08-08[llvm] LLVM_FALLTHROUGH => [[fallthrough]]. NFCFangrui Song
With C++17 there is no Clang pedantic warning or MSVC C5051.
2022-06-08[SystemZ] Use STDY/STEY/LDY/LEY for VR32/VR64 in eliminateFrameIndex().Jonas Paulsson
When e.g. a VR64 register is spilled to a stack slot requiring a long (20-bit) displacement, it is possible to use an FP opcode if the allocated phys reg allows it. This eliminates the use of a separate LAY instruction. Reviewed By: Ulrich Weigand Differential Revision: https://reviews.llvm.org/D115406
2022-06-04[Target] Use MachineBasicBlock::erase (NFC)Kazu Hirata
2022-03-16[NFC][CodeGen] Rename some functions in MachineInstr.h and remove duplicated ↵Shengchen Kan
comments
2022-03-16Cleanup codegen includesserge-sans-paille
This is a (fixed) recommit of https://reviews.llvm.org/D121169 after: 1061034926 before: 1063332844 Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D121681
2022-03-10Revert "Cleanup codegen includes"Nico Weber
This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20. Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang, and many LLVM tests, see comments on https://reviews.llvm.org/D121169
2022-03-10Cleanup codegen includesserge-sans-paille
after: 1061034926 before: 1063332844 Differential Revision: https://reviews.llvm.org/D121169
2022-02-14[SystemZ/z/OS] Add XPLINK dynamic stack allocationKai Nacke
With XPLINK, dynamic stack allocations requires calling a runtime function, which allocates the stack memory, moves the register save area, and returns the new stack pointer. Reviewed By: uweigand Differential Revision: https://reviews.llvm.org/D119732
2022-02-11[SystemZ/z/OS] Add alias for XPLINK returnKai Nacke
The XPLINK return `b 2(7)` has size 4 bytes, while the Linux return `br 7` only has size 2 bytes. Thus a new alias is required to have correct instruction byte count. It also fixes the conditional return code. Reviewed By: uweigand Differential Revision: https://reviews.llvm.org/D119437
2022-01-27[SystemZ] Implement orderFrameObjects().Jonas Paulsson
By reordering the objects on the stack frame after looking at the users, a better utilization of displacement operands will result. This means less needed Load Address instructions for the accessing of these objects. This is important for very large functions where otherwise small changes could cause a lot more/less accesses go out of range. Note: this is not yet enabled for SystemZXPLINKFrameLowering, but should be. Review: Ulrich Weigand Differential Revision: https://reviews.llvm.org/D115690
2022-01-19[NFC] Use Register instead of unsignedJim Lin
2021-11-27[Target] Use range-based for loops (NFC)Kazu Hirata