summaryrefslogtreecommitdiff
path: root/llvm/lib/Target/SystemZ/SystemZAsmPrinter.cpp
AgeCommit message (Collapse)Author
2025-07-02[SystemZ][HLASM] Emit END instruction (#146110)Kai Nacke
A HLASM source file must end with the END instruction. It is implemented by adding a new function to the target streamer. This change also turns SystemZHLASMSAsmString.h into a proper header file, and only uses the SystemZTargetHLASMStreamer when HLASM output is generated.
2025-06-26[GOFF] Add writing of section symbols (#133799)Kai Nacke
Unlike other formats, the GOFF object file format uses a 2 dimensional structure to define the location of data. For example, the equivalent of the ELF .text section is made up of a Section Definition (SD) and a class (Element Definition; ED). The name of the SD symbol depends on the application, while the class has the predefined name C_CODE/C_CODE64 in AMODE31 and AMODE64 respectively. Data can be placed into this structure in 2 ways. First, the data (in a text record) can be associated with an ED symbol. To refer to data, a Label Definition (LD) is used to give an offset into the data a name. When binding, the whole data is pulled into the resulting executable, and the addresses given by the LD symbols are resolved. The alternative is to use a Part Definition (PR). In this case, the data (in a text record) is associated with the part. When binding, only the data of referenced PRs is pulled into the resulting binary. Both approaches are used. SD, ED, and PR elements are modeled by nested MCSectionGOFF instances, while LD elements are associated with MCSymbolGOFF instances. At the binary level, a record called "External Symbol Definition" (ESD) is used. The ESD has a type (SD, ED, PR, LD), and depending on the type a different subset of the fields is used.
2025-06-17[llvm] annotate interfaces in llvm/Target for DLL export (#143615)Andrew Rogers
## 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
2025-06-15SystemZ: Migrate to newer relocation specifier representationFangrui Song
z/OS creates SystemZMCExpr objects (https://reviews.llvm.org/D153788) while ELF doesn't. Define the SystemZMCAsmInfoGOFF hooks instead of the legacy MCSpecifierExpr:: hooks.
2025-06-15SystemZ: Rename SystemZMCExpr::VK_ to SystemZ::S_Fangrui Song
Prepare for removing SystemZMCExpr. Adopt the newer naming convention used by most other targets.
2025-06-15SystemZ: Replace deprecated MCExpr::print with MCAsmInfo::printExprFangrui Song
2025-05-06Register assembly printer passes (#138348)Matthias Braun
Register assembly printer passes in the pass registry. This makes it possible to use `llc -start-before=<target>-asm-printer ...` in tests. Adds a `char &ID` parameter to the AssemblyPrinter constructor to allow targets to use the `INITIALIZE_PASS` macros and register the pass in the pass registry. This currently has a default parameter so it won't break any targets that have not been updated.
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-22Move SystemZ-specific MCSymbolRefExpr::VariantKind to SystemZMCExpr::SpecifierFangrui Song
Similar to previous migration done for other targets (PowerPC, X86, ARM, etc). Switch from the confusing VariantKind to Specifier, which aligns with Arm and IBM AIX's documentation. In addition, rename *MCExpr::getKind, which confusingly shadows the base class getKind. In the future, relocation specifiers should be encoded as part of SystemZMCExpr instead of MCSymbolRefExpr.
2025-03-06[MC] Remove unneeded VK_None argument from MCSymbolRefExpr::create. NFCFangrui Song
2025-02-11[SystemZ] Avoid repeated hash lookups (NFC) (#126679)Kazu Hirata
2024-12-10SystemZ: Add support for __builtin_setjmp and __builtin_longjmp. (#119257)anoopkg6
This pr includes fixes for original pr##116642. Implementation for __builtin_setjmp and __builtin_longjmp for SystemZ..
2024-12-07Revert "[SystemZ] Add support for __builtin_setjmp and __builtin_longjmp ↵Ulrich Weigand
(#116642)" This reverts commit 030bbc92a705758f1131fb29cab5be6d6a27dd1f.
2024-12-06[SystemZ] Add support for __builtin_setjmp and __builtin_longjmp (#116642)anoopkg6
Implementation for __builtin_setjmp and __builtin_longjmp for SystemZ.
2024-11-18[Target] Remove unused includes (NFC) (#116577)Kazu Hirata
Identified with misc-include-cleaner.
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-10-22[SystemZ] Split SystemZInstPrinter to two classes based on Asm dialect (#112975)tltao
In preparation for future work on separating the output of the GNU/HLASM ASM dialects, we first separate the SystemZInstPrinter classes to two versions, one for each ASM dialect. The common code remains in a SystemZInstPrinterCommon class instead. --------- Co-authored-by: Tony Tao <tonytao@ca.ibm.com>
2024-08-01[SystemZ][z/OS] Fix incorrect codegen for ADA_ENTRY pseudo instruction (#101415)tltao
The current MCInstBuilder for generating an ALGFI when loading something from the ADA is incorrect and will crash the compiler. r0 must also be excluded from the registers returned as the result, since it is treated as the value "0" on z/OS. Also add some tests to properly test the paths where LLILF and ALGFI are generated. --------- Co-authored-by: Tony Tao <tonytao@ca.ibm.com>
2024-06-28[IR] Don't include Module.h in Analysis.h (NFC) (#97023)Nikita Popov
Replace it with a forward declaration instead. Analysis.h is pulled in by all passes, but not all passes need to access the module.
2024-03-05[SystemZ] [z/OS] Emit offset to PPA2 in separate MCSection (#84043)Neumann Hon
The ppa2list section isn't really part of the ppa2 section. The ppa2list section contains the offset to the ppa2, and must be created with a special section name (specifically, C_@@QPPA2). The binder searches for a section with this name, then uses this value to locate the ppa2. In GOFF terms, these are entirely separate sections; the PPA2 section isn't even really a section but rather belongs to the code section. On the other hand, the ppa2list section is a section in its own right and resides in a separate TXT record.
2024-02-07[SystemZ] Implement A, O and R inline assembly format flags (#80685)Ilya Leoshkevich
Implement the following assembly format flags, which are already supported by GCC: 'A': On z14 or higher: If operand is a mem print the alignment hint usable with vl/vst prefixed by a comma. 'O': print only the displacement of a memory reference or address. 'R': print only the base register of a memory reference or address. Implement 'A' conservatively, since the memory operand alignment information is not available for INLINEASM at the moment.
2023-12-19[SystemZ][z/OS] Add exception handling for XPLINK (#74638)Yusra Syeda
Adds emitting the exception table and the EH registers for XPLINK. --------- Co-authored-by: Yusra Syeda <yusra.syeda@ibm.com>
2023-12-04[SystemZ] Handle index-only addresses in (dis)assemblerUlrich Weigand
Most addresses in SystemZ instructions take two registers, an index register and a base register. However, either of those can be omitted. If there is just a single register, this usually is taken as the base register - however, there are certain rare cases where you specifically want to use an index register but no base register. This is currently not handled consistently by the assembler / disassembler. Fix this by - always emitting a dummy 0 as base register for index- only addresses - correctly handle dummy 0 as indicating no base register when parsing an address This is compatible with current GNU binutils behavior.
2023-11-27[SystemZ][z/OS] This change adds support for the PPA2 section in zOS (#68926)Yusra Syeda
This PR adds support for the PPA2 fields. --------- Co-authored-by: Yusra Syeda <yusra.syeda@ibm.com>
2023-08-23[SystemZ][z/OS] Fix the entry point marker for leaf functionsNeumann Hon
The function emitFunctionEntryLabel does not look at whether or not a function is a leaf when setting the entry flags, and instead blindly marks all functions as non-leaf routines. Differential Revision: https://reviews.llvm.org/D157701 Reviewed By: uweigand
2023-08-20Revert "[SystemZ][z/OS] Fix the entry point marker for leaf functions"Neumann Hon
This reverts commit 8af297bbb8e97de8908b857eae1a44f46a0d5afe. Testcase LLVM :: MC/GOFF/ppa1.ll needs to be updated to account for this.
2023-08-20[SystemZ][z/OS] Fix the entry point marker for leaf functionsNeumann Hon
The function emitFunctionEntryLabel does not look at whether or not a function is a leaf when setting the entry flags, and instead blindly marks all functions as non-leaf routines. Change it to check if a function is a leaf function and mark it accordingly.
2023-08-10[SystemZ][z/OS] Add support for function name field of PPA1Neumann Hon
This PR causes the PPA1 to emit the function's name if it exists. This field is not emitted for unnamed functions. Reviewed By: uweigand Differential Revision: https://reviews.llvm.org/D157494
2023-07-06[SystemZ][z/OS] Address single comment in ADA patch for EmittedBytes unused ↵Yusra Syeda
in -Asserts
2023-07-05[SystemZ][z/OS] z/OS ADA codegen and emissionYusra Syeda
This patch adds support for the ADA (associated data area), doing the following: -Creates the ADA table to handle displacements -Emits the ADA section in the SystemZAsmPrinter -Lowers the ADA_ENTRY node into the appropriate load instruction Differential Revision: https://reviews.llvm.org/D153788
2023-06-28Revert "[SystemZ][z/OS] This patch adds support for the ADA (associated data ↵Yusra Syeda
area), doing the following:" This reverts commit 9df0f66af5462e23216eae31aedbd4d2f459cc3d.
2023-06-28[SystemZ][z/OS] This patch adds support for the ADA (associated data area), ↵Yusra Syeda
doing the following: - Creates the ADA table to handle displacements - Emits the ADA section in the SystemZAsmPrinter - Lowers the ADA_ENTRY node into the appropriate load instruction Differential Revision: https://reviews.llvm.org/D153788
2023-06-25[llvm] Add missing StringExtras.h includesElliot Goodrich
In preparation for removing the `#include "llvm/ADT/StringExtras.h"` from the header to source file of `llvm/Support/Error.h`, first add in all the missing includes that were previously included transitively through this header.
2023-06-14[SystemZ][z/OS] Correct value of length/4 of params field in PPA1.Neumann Hon
The Length/4 of Params field in the PPA1 ought to be the length of the parameters for the current function. Currently we are storing the length of the parameter area in the current function's stack frame, which represents the length of the params of the longest callee in the current function. Differential Revision: https://reviews.llvm.org/D152920 Reviewed By: uweigand
2023-06-14Revert "[SystemZ][z/OS] Correct value of length/4 of params field in PPA1."Neumann Hon
This reverts commit e0f7b0e0f704dc3759925602e474b9e669270fcb.
2023-06-14[SystemZ][z/OS] Correct value of length/4 of params field in PPA1.Neumann Hon
The Length/4 of Params field in the PPA1 ought to be the length of the parameters for the current function. Currently we are storing the length of the parameter area in the current function's stack frame, which represents the length of the params of the longest callee in the current function. Differential revision: https://reviews.llvm.org/D119049 Reviewed By: uweigand
2023-02-17Simplify with hasFeature. NFCFangrui Song
2023-01-11[CodeGen] Introduce a generic MEMBARRIER instruction [mostly-nfc]Philip Reames
This is a follow up to D141317 which extends the common code to include a target independent pseudo instruction. This is an alternative to (subset of) D92842 which tries to be as close to NFC as possible. A couple things to call out. * The test change in X86 is because we loose the scheduling information on the instruction. However, I think this was actually a bug in x86 since no instruction was emitted for a MEMBARRIER. Concluding that a meta instruction has latency just seems wrong? * I intentionally left some parts of D92842 out. Specifically, several of the changes in the X86 code (data independence and outlining) appear functional, and likely worthy of their own review. Additionally, I'm not handling ARM/AArch64 at all. Those targets need the ordering whereas none of the others do. I want to get this in and tested before retrofitting in ordering to support those targets. Differential Revision: https://reviews.llvm.org/D141408
2022-12-06[SystemZ] Emit a .gnu_attribute for an externally visible vector abi.Jonas Paulsson
On SystemZ, the vector ABI changes depending on the presence of hardware vector support. Therefore, each binary compiled with a visible vector ABI (e.g. one that calls an external function with a vector argument) should be marked with a .gnu_attribute describing this. Reviewed By: uweigand Differential Revision: https://reviews.llvm.org/D105067
2022-10-25[SystemZInstPrinter] Introduce markup tags emissionUlrich Weigand
SystemZ assembly syntax emission now leverages markup tags, if enabled. Author: Antonio Frighetto Differential Revision: https://reviews.llvm.org/D129868
2022-09-06[MC] Emit Stackmaps before debug infoMarkus Böck
This patch is essentially an alternative to https://reviews.llvm.org/D75836 and was mentioned by @lhames in a comment. The gist of the issue is that Mach-O has restrictions on which kind of sections are allowed after debug info has been emitted, which is also properly asserted within LLVM. Problem is that stack maps are currently emitted as one of the last sections in each target-specific AsmPrinter so far, which would cause the assertion to trigger. The current approach of special casing for the `__LLVM_STACKMAPS` section is not viable either, as downstream users can overwrite the stackmap format using plugins, which may want to use different sections. This patch fixes the issue by emitting the stack map earlier, right before debug info is emitted. The way this is implemented is by taking the choice when to emit the StackMap away from the target AsmPrinter and doing so in the base class. The only disadvantage of this approach is that the `StackMaps` member is now part of the base class, even for targets that do not support them. This is functionaly not a problem however, as emitting an empty `StackMaps` is a no-op. Differential Revision: https://reviews.llvm.org/D132708
2022-07-14[CodeGen] Move instruction predicate verification to emitInstructionDavid Green
D25618 added a method to verify the instruction predicates for an emitted instruction, through verifyInstructionPredicates added into <Target>MCCodeEmitter::encodeInstruction. This is a very useful idea, but the implementation inside MCCodeEmitter made it only fire for object files, not assembly which most of the llvm test suite uses. This patch moves the code into the <Target>_MC::verifyInstructionPredicates method, inside the InstrInfo. The allows it to be called from other places, such as in this patch where it is called from the <Target>AsmPrinter::emitInstruction methods which should trigger for both assembly and object files. It can also be called from other places such as verifyInstruction, but that is not done here (it tends to catch errors earlier, but in reality just shows all the mir tests that have incorrect feature predicates). The interface was also simplified slightly, moving computeAvailableFeatures into the function so that it does not need to be called externally. The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently show errors in the test-suite, so have been disabled with FIXME comments. Recommitted with some fixes for the leftover MCII variables in release builds. Differential Revision: https://reviews.llvm.org/D129506
2022-07-13Revert "Move instruction predicate verification to emitInstruction"David Green
This reverts commit e2fb8c0f4b940e0285ee36c112469fa75d4b60ff as it does not build for Release builds, and some buildbots are giving more warning than I saw locally. Reverting to fix those issues.
2022-07-13Move instruction predicate verification to emitInstructionDavid Green
D25618 added a method to verify the instruction predicates for an emitted instruction, through verifyInstructionPredicates added into <Target>MCCodeEmitter::encodeInstruction. This is a very useful idea, but the implementation inside MCCodeEmitter made it only fire for object files, not assembly which most of the llvm test suite uses. This patch moves the code into the <Target>_MC::verifyInstructionPredicates method, inside the InstrInfo. The allows it to be called from other places, such as in this patch where it is called from the <Target>AsmPrinter::emitInstruction methods which should trigger for both assembly and object files. It can also be called from other places such as verifyInstruction, but that is not done here (it tends to catch errors earlier, but in reality just shows all the mir tests that have incorrect feature predicates). The interface was also simplified slightly, moving computeAvailableFeatures into the function so that it does not need to be called externally. The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently show errors in the test-suite, so have been disabled with FIXME comments. Differential Revision: https://reviews.llvm.org/D129506
2022-06-20[SystemZ] Remove unnecessary casts to SystemZInstrInfo (NFC).Jonas Paulsson
Review: Ulrich Weigand
2022-06-10[MC] De-capitalize SwitchSection. NFCFangrui Song
Add SwitchSection to return switchSection. The API will be removed soon.
2022-06-07[MC] De-capitalize MCStreamer functionsFangrui Song
Follow-up to c031378ce01b8485ba0ef486654bc9393c4ac024 . The class is mostly consistent now.
2022-05-26[Target] use getSubtarget<> instead of static_cast<>(getSubtarget())Zongwei Lan
Differential Revision: https://reviews.llvm.org/D125391
2022-05-21SystemZAsmPrinter.cpp: Fix a warning. [-Wunused-variable]NAKAMURA Takumi
This could be rewritten as `!ZFL->hasFP(*MF) || FrameReg < 16` but I thought better to clarify it is `AllocaReg`.
2022-05-18[SystemZ][z/OS] Add the PPA1 to SystemZAsmPrinterYusra Syeda
Differential Revision: https://reviews.llvm.org/D125725