| commit | 083b4a3d66c2d3e87b9b35104b59e07a004b5d3e | [log] [tgz] |
|---|---|---|
| author | Dominik Steenken <dost@de.ibm.com> | Fri May 02 12:42:58 2025 +0200 |
| committer | GitHub <noreply@github.com> | Fri May 02 12:42:58 2025 +0200 |
| tree | a0c8c41ee3e717b24f89a9567ecf49303d7e8657 | |
| parent | 4ba27780d34916d4a856e6593035b15a5cace56e [diff] |
[SystemZ] Add proper mcount handling (#135767) When compiling with `-pg`, the `EntryExitInstrumenterPass` will insert calls to the glibc function `mcount` at the begining of each `MachineFunction`. On SystemZ, these calls require special handling: - The call to `mcount` needs to happen at the beginning of the prologue. - Prior to the call to `mcount`, register `%r14`, the return address of the callee function, must be stored 8 bytes above the stack pointer `%r15`. After the call to `mcount` returns, that register needs to be restored. This commit adds some special handling to the EntryExitInstrumenterPass that keeps the insertion of the mcount function into the module, but skips over insertion of the actual call in order to perform this insertion in the `emitPrologue` function. There, a simple sequence of store/call/load is inserted, which implements the above. The desired change in the `EntryExitInstrumenterPass` necessitated the addition of a new attribute and attribute kind to each function, which is used to trigger the postprocessing, aka call insertion, in `emitPrologue`. Note that the new attribute must be of a different kind than the `mcount` atribute, since otherwise it would replace that attribute and later be deleted by the code that intended to delete `mcount`. The new attribnute is called `insert-mcount`, while the attribute kind is `systemz-backend`, to clearly mark it as a SystemZ-specific backend concern. This PR should address issue #121137 . The test inserted here is derived from the example given in that issue.
Welcome to the LLVM project!
This repository contains the source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.
The LLVM project has multiple components. The core of the project is itself called “LLVM”. This contains all of the tools, libraries, and header files needed to process intermediate representations and convert them into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer.
C-like languages use the Clang frontend. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.
Other components include: the libc++ C++ standard library, the LLD linker, and more.
Consult the Getting Started with LLVM page for information on building and running LLVM.
For information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.
Join the LLVM Discourse forums, Discord chat, LLVM Office Hours or Regular sync-ups.
The LLVM project has adopted a code of conduct for participants to all modes of communication within the project.