[SystemZ][z/OS] Implement detection and handling for XPLink Leaf procedures.

This PR adds support for creating leaf functions when there are no CSRs used, no function calls are made, no stack frame

[SystemZ][z/OS] Implement detection and handling for XPLink Leaf procedures.

This PR adds support for creating leaf functions when there are no CSRs used, no function calls are made, no stack frame is acquired, and contain no try/catch/throw statements.

Reviewed By: uweigand

Differential Revision: https://reviews.llvm.org/D129687

show more ...

[SystemZ] [z/OS] Add support for generating huge (1 MiB) stack frames in XPLINK64

This patch extends support for generating huge stack frames on 64-bit XPLINK by implementing the ABI-mandated call t

[SystemZ] [z/OS] Add support for generating huge (1 MiB) stack frames in XPLINK64

This patch extends support for generating huge stack frames on 64-bit XPLINK by implementing the ABI-mandated call to the stack extension routine.

Reviewed By: uweigand

Differential Revision: https://reviews.llvm.org/D120450

show more ...

[SystemZ] Implement orderFrameObjects().

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 Lo

[SystemZ] Implement orderFrameObjects().

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

show more ...

[Target] Remove unused forward declarations (NFC)

[z/OS] Implement prologue and epilogue generation for z/OS target.

This patch adds support for prologue and epilogue generation for the z/OS target under the XPLINK64 ABI for functions with a stack

[z/OS] Implement prologue and epilogue generation for z/OS target.

This patch adds support for prologue and epilogue generation for the z/OS target under the XPLINK64 ABI for functions with a stack size of less than 1048576 bytes (huge stack frames).

Reviewed By: uweigand

Differential Revision: https://reviews.llvm.org/D114457

show more ...

Revert "[z/OS] Implement prologue and epilogue generation for z/OS target."

This reverts commit ffad4d777b227f91be04020e2cd86ab38e969e39 because it introduced buildbot failures.

[z/OS] Implement prologue and epilogue generation for z/OS target.

This patch adds support for prologue and epilogue generation for
the z/OS target under the XPLINK64 ABI for functions with a stack

[z/OS] Implement prologue and epilogue generation for z/OS target.

This patch adds support for prologue and epilogue generation for
the z/OS target under the XPLINK64 ABI for functions with a stack
size of less than 1048576 bytes (huge stack frames).

Reviewed by: uweigand, Kai

Differential Revision: https://reviews.llvm.org/D114457

show more ...

PrologEpilogInserter: Use explicit control for scavenge slot placement

AMDGPU is unusual in that the both stack is indexed in the same
direction as stack growth (up). We therefore always need the em

PrologEpilogInserter: Use explicit control for scavenge slot placement

AMDGPU is unusual in that the both stack is indexed in the same
direction as stack growth (up). We therefore always need the emergency
stack slots placed as low as possible to ensure they are in range of
load/store instruction immediate offsets. The existing logic is mostly
OK, but failed if we required stack realignment.

I don't understand what the existing control isFPCloseToIncomingSP is
supposed to mean, but can only be used to stop placing the scavenge
slots earlier. Make this explicit so that targets can opt-in rather
than opt-out only.

show more ...

[SystemZ/z/OS] Implement save of non-volatile registers on z/OS XPLINK

This PR implements the save of the XPLINK callee-saved registers
on z/OS.

Reviewed By: uweigand, Kai

Differential Revision: h

[SystemZ/z/OS] Implement save of non-volatile registers on z/OS XPLINK

This PR implements the save of the XPLINK callee-saved registers
on z/OS.

Reviewed By: uweigand, Kai

Differential Revision: https://reviews.llvm.org/D111653

show more ...

[SystemZ] [NFC] Add SystemZELFFrameLowering and SystemZXPLINKFrameLowering classes.

This patch adds class SystemZFrameLowering which is a SystemZ-specific class
detailing special registers used by c

[SystemZ] [NFC] Add SystemZELFFrameLowering and SystemZXPLINKFrameLowering classes.

This patch adds class SystemZFrameLowering which is a SystemZ-specific class
detailing special registers used by calling conventions on the target.
SystemZELFFrameLowering and SystemZXPLINKFrameLowering implement this class
for ELF and XPLINK64 respectively. Previous functionality in SystemZFrameLowering
is moved to SystemZELFFrameLowering. SystemZXPLINKFrameLowering can then be
implemented in future patches.

Reviewed By: uweigand, Kai

Differential Revision: https://reviews.llvm.org/D108777

show more ...

[SystemZ][NFC] Renaming of ELF specific variables.

Rename ELF specific variables, making it easier to add the XPLink
variables in future patches.

Reviewed By: abhina.sreeskantharajan, Kai

Differen

[SystemZ][NFC] Renaming of ELF specific variables.

Rename ELF specific variables, making it easier to add the XPLink
variables in future patches.

Reviewed By: abhina.sreeskantharajan, Kai

Differential Revision: https://reviews.llvm.org/D98199

show more ...

[SystemZ] Improve handling of backchain offset.

- New function SDValue getBackchainAddress() used by
lowerDYNAMIC_STACKALLOC() and lowerSTACKRESTORE() to properly handle the
backchain offset als

[SystemZ] Improve handling of backchain offset.

- New function SDValue getBackchainAddress() used by
lowerDYNAMIC_STACKALLOC() and lowerSTACKRESTORE() to properly handle the
backchain offset also with packed-stack.

- Make a common function getBackchainOffset() for the computation of the
backchain offset and use in some places (NFC).

Review: Ulrich Weigand

Differential Revision: https://reviews.llvm.org/D93171

show more ...

[SVE] Return StackOffset for TargetFrameLowering::getFrameIndexReference.

To accommodate frame layouts that have both fixed and scalable objects
on the stack, describing a stack location or offset u

[SVE] Return StackOffset for TargetFrameLowering::getFrameIndexReference.

To accommodate frame layouts that have both fixed and scalable objects
on the stack, describing a stack location or offset using a pointer + uint64_t
is not sufficient. For this reason, we've introduced the StackOffset class,
which models both the fixed- and scalable sized offsets.

The TargetFrameLowering::getFrameIndexReference is made to return a StackOffset,
so that this can be used in other interfaces, such as to eliminate frame indices
in PEI or to emit Debug locations for variables on the stack.

This patch is purely mechanical and doesn't change the behaviour of how
the result of this function is used for fixed-sized offsets. The patch adds
various checks to assert that the offset has no scalable component, as frame
offsets with a scalable component are not yet supported in various places.

Reviewed By: arsenm

Differential Revision: https://reviews.llvm.org/D90018

show more ...

[SystemZ] Implement -fstack-clash-protection

Probing of allocated stack space is now done when this option is passed. The
purpose is to protect against the stack clash attack (see
https://www.qualys

[SystemZ] Implement -fstack-clash-protection

Probing of allocated stack space is now done when this option is passed. The
purpose is to protect against the stack clash attack (see
https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt).

Review: Ulrich Weigand

Differential Revision: https://reviews.llvm.org/D78717

show more ...

CodeGen: Use Register in TargetFrameLowering

ArrayRef'ize restoreCalleeSavedRegisters. NFCI.

restoreCalleeSavedRegisters can mutate the contents of the
CalleeSavedInfos, so use a MutableArrayRef.

[SystemZ] Support the kernel back chain.

In order to build the Linux kernel, the back chain must be supported with
packed-stack. The back chain is then stored topmost in the register save
area.

Re

[SystemZ] Support the kernel back chain.

In order to build the Linux kernel, the back chain must be supported with
packed-stack. The back chain is then stored topmost in the register save
area.

Review: Ulrich Weigand

Differential Revision: https://reviews.llvm.org/D74506

show more ...

ArrayRef'ize spillCalleeSavedRegisters. NFCI.

[SystemZ] Implement the packed stack layout

Any llvm function with the "packed-stack" attribute will be compiled to use
the packed stack layout which reuses unused parts of the incoming register
sa

[SystemZ] Implement the packed stack layout

Any llvm function with the "packed-stack" attribute will be compiled to use
the packed stack layout which reuses unused parts of the incoming register
save area. This is needed for building the Linux kernel.

Review: Ulrich Weigand
https://reviews.llvm.org/D70821

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[SystemZ] Fix common-code users of stack size

On SystemZ we need to provide a register save area of 160 bytes to
any called function. This size needs to be added when allocating
stack in the functi

[SystemZ] Fix common-code users of stack size

On SystemZ we need to provide a register save area of 160 bytes to
any called function. This size needs to be added when allocating
stack in the function prologue. However, it was not accounted for
as part of MachineFrameInfo::getStackSize(); instead the back-end
used a private routine getAllocatedStackSize().

This is OK for code-gen purposes, but it breaks other users of
the getStackSize() routine, in particular it breaks the recently-
added -stack-size-section feature.

Fix this by updating the main stack size tracked by common code
(in emitPrologue) instead of using the private routine.

No change in code generation intended.

llvm-svn: 326610

show more ...

Move TargetFrameLowering.h to CodeGen where it's implemented

This header already includes a CodeGen header and is implemented in
lib/CodeGen, so move the header there to match.

This fixes a link er

Move TargetFrameLowering.h to CodeGen where it's implemented

This header already includes a CodeGen header and is implemented in
lib/CodeGen, so move the header there to match.

This fixes a link error with modular codegeneration builds - where a
header and its implementation are circularly dependent and so need to be
in the same library, not split between two like this.

llvm-svn: 317379

show more ...

Add "Restored" flag to CalleeSavedInfo

The liveness-tracking code assumes that the registers that were saved
in the function's prolog are live outside of the function. Specifically,
that registers t

Add "Restored" flag to CalleeSavedInfo

The liveness-tracking code assumes that the registers that were saved
in the function's prolog are live outside of the function. Specifically,
that registers that were saved are also live-on-exit from the function.
This isn't always the case as illustrated by the LR register on ARM.

Differential Revision: https://reviews.llvm.org/D36160

llvm-svn: 310619

show more ...

Change eliminateCallFramePseudoInstr() to return an iterator

This will become necessary in a subsequent change to make this method
merge adjacent stack adjustments, i.e. it might erase the previous

Change eliminateCallFramePseudoInstr() to return an iterator

This will become necessary in a subsequent change to make this method
merge adjacent stack adjustments, i.e. it might erase the previous
and/or next instruction.

It also greatly simplifies the calls to this function from Prolog-
EpilogInserter. Previously, that had a bunch of logic to resume iteration
after the call; now it just continues with the returned iterator.

Note that this changes the behaviour of PEI a little. Previously,
it attempted to re-visit the new instruction created by
eliminateCallFramePseudoInstr(). That code was added in r36625,
but I can't see any reason for it: the new instructions will obviously
not be pseudo instructions, they will not have FrameIndex operands,
and we have already accounted for the stack adjustment.

Differential Revision: http://reviews.llvm.org/D18627

llvm-svn: 265036

show more ...

Remove redundant TargetFrameLowering::getFrameIndexOffset virtual
function.

This was the same as getFrameIndexReference, but without the FrameReg
output.

Differential Revision: http://reviews.llvm.

Remove redundant TargetFrameLowering::getFrameIndexOffset virtual
function.

This was the same as getFrameIndexReference, but without the FrameReg
output.

Differential Revision: http://reviews.llvm.org/D12042

llvm-svn: 245148

show more ...