[SystemZ][z/OS] Introduce CCAssignToRegAndStack to calling convention

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

Reland "[SystemZ][z/OS] Fix f32 variadic argument assertion"

This patch relands the f32 vararg assertion on z/OS fix that was reverted previously due to the testcase failing on non-z/OS platforms. I

Reland "[SystemZ][z/OS] Fix f32 variadic argument assertion"

This patch relands the f32 vararg assertion on z/OS fix that was reverted previously due to the testcase failing on non-z/OS platforms. It is now passing.

The tablegen lines that specify the XPLINK64 calling convention for promoting an f32 vararg to an f64 are effectively overwritten by the following tablegen line which bitcast an f64 vararg to an i64 (so that it can be used in the GPRs). Thus it becomes a bitcast from f32 to i64. We don't handle bitcasts for f32s and so this causes an assertion to be thrown.

We fix this by simplifying the tablegen lines to explicity show this behaviour, and allow the f32 in the bitcast case by first promoting it to an f64.

show more ...

[SystemZ] [z/OS] Use assignCalleeSavedSpillSlots() to mark handle special registers in CSR list instead of determineCalleeSave

This PR moves the handling of special registers that need to be saved/r

[SystemZ] [z/OS] Use assignCalleeSavedSpillSlots() to mark handle special registers in CSR list instead of determineCalleeSave

This PR moves the handling of special registers that need to be saved/restored in the prolog/epilog respectively from determineCalleeSaves to assignCalleeSavedSpillSlots. The documentation of the parent function of assignCalleeSavedSpillSlots explicitly allows the modification of the CSI hence adding the special registers (the stack pointer register, the return address register, and the entry point register) to the CSI list at that stage should be permissible.

This cleans up the code a bit and makes it so that we do not have to place registers that are not actually considered CSRs by the spec in the CSR list, which is something of a hack.

Reviewed By: uweigand

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

show more ...

Revert [SystemZ][z/OS] Fix f32 variadic argument assertion

This reverts ea0676f97d734196b15da7553cd407e6a36cef2d

[SystemZ][z/OS] Fix f32 variadic argument assertion

The tablegen lines that specify the XPLINK64 calling convention for promoting an f32 vararg to an f64 are effectively overwritten by the following

[SystemZ][z/OS] Fix f32 variadic argument assertion

The tablegen lines that specify the XPLINK64 calling convention for promoting an f32 vararg to an f64 are effectively overwritten by the following tablegen line which bitcast an f64 vararg to an i64 (so that it can be used in the GPRs). It becomes a bitcast from f32 to i64.

Since we don't handle a bitcast for f32s this caused an assertion.

show more ...

[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 ...

[SystemZ][z/OS] Initial implementation for lowerCall on z/OS

- This patch provides the initial implementation for lowering a call on z/OS according to the XPLINK64 calling convention
- A series of c

[SystemZ][z/OS] Initial implementation for lowerCall on z/OS

- This patch provides the initial implementation for lowering a call on z/OS according to the XPLINK64 calling convention
- A series of changes have been made to SystemZCallingConv.td to account for these additional XPLINK64 changes including adding a new helper function to shadow the stack along with allocation of a register wherever appropriate
- For the cases of copying a f64 to a gr64 and a f128 / 128-bit vector type to a gr64, a `CCBitConvertToType` has been added and has been bitcasted appropriately in the lowering phase
- Support for the ADA register (R5) will be provided in a later patch.

Reviewed By: uweigand

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

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] [z/OS] Add XPLINK64 Calling Convention to SystemZ

This patch adds the XPLINK64 calling convention to the SystemZ
backend. It specifies and implements the argument passing and
return value

[SystemZ] [z/OS] Add XPLINK64 Calling Convention to SystemZ

This patch adds the XPLINK64 calling convention to the SystemZ
backend. It specifies and implements the argument passing and
return value conventions.

Reviewed By: uweigand

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

show more ...

[SystemZ/z/OS] Add XPLINK 64-bit calling convention to tablegen.

This commit adds the initial changes to the SystemZ target
description for the XPLINK 64-bit calling convention on z/OS.
Additions in

[SystemZ/z/OS] Add XPLINK 64-bit calling convention to tablegen.

This commit adds the initial changes to the SystemZ target
description for the XPLINK 64-bit calling convention on z/OS.
Additions include:

- a new predicate IsTargetXPLINK64
- different register allocation order
- generaton of nopr after a call

Reviewed-by: uweigand

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

show more ...

[SystemZ] Separate LoZ ELF specifics in tablegen.

Separate the LoZ ELF calling convention in tablegen.
This will make it easier to add the z/OS ABI in future patches.

Reviewed By: uweigand

Differe

[SystemZ] Separate LoZ ELF specifics in tablegen.

Separate the LoZ ELF calling convention in tablegen.
This will make it easier to add the z/OS ABI in future patches.

Reviewed By: uweigand

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

show more ...

[SystemZ] Add GHC calling convention

This is a special calling convention to be used by the GHC compiler.

Author: Stefan Schulze Frielinghaus
Differential Revision: https://reviews.llvm.org/D69024

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] Add support for anyregcc calling convention

This adds back-end support for the anyregcc calling convention
for use with patchpoints.

Since all registers are considered call-saved with any

[SystemZ] Add support for anyregcc calling convention

This adds back-end support for the anyregcc calling convention
for use with patchpoints.

Since all registers are considered call-saved with anyregcc
(except for 0 and 1 which may still be clobbered by PLT stubs
and the like), this required adding support for saving and
restoring vector registers in prologue/epilogue code for the
first time. This is not used by any other calling convention.

llvm-svn: 326612

show more ...

[SystemZ] Support Swift Calling Convention

Summary:
Port rL265480, rL264754, rL265997 and rL266252 to SystemZ, in order to enable the Swift port on the architecture. SwiftSelf and SwiftError are ass

[SystemZ] Support Swift Calling Convention

Summary:
Port rL265480, rL264754, rL265997 and rL266252 to SystemZ, in order to enable the Swift port on the architecture. SwiftSelf and SwiftError are assigned to R10 and R9, respectively, which are normally callee-saved registers. For more information, see:

RFC: Implementing the Swift calling convention in LLVM and Clang
https://groups.google.com/forum/#!topic/llvm-dev/epDd2w93kZ0

Reviewers: kbarton, manmanren, rjmccall, uweigand

Subscribers: llvm-commits

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

llvm-svn: 267823

show more ...

[SystemZ] Fix ABI for i128 argument and return types

According to the SystemZ ABI, 128-bit integer types should be
passed and returned via implicit reference. However, this is
not currently impleme

[SystemZ] Fix ABI for i128 argument and return types

According to the SystemZ ABI, 128-bit integer types should be
passed and returned via implicit reference. However, this is
not currently implemented at the LLVM IR level for the i128
type. This does not matter when compiling C/C++ code, since
clang will implement the implicit reference itself.

However, it turns out that when calling libgcc helper routines
operating on 128-bit integers, LLVM will use i128 argument and
return value types; the resulting code is not compatible with
the ABI used in libgcc, leading to crashes (see PR26559).

This should be simple to fix, except that i128 currently is not
even a legal type for the SystemZ back end. Therefore, common
code will already split arguments and return values into multiple
parts. The bulk of this patch therefore consists of detecting
such parts, and correctly handling passing via implicit reference
of a value split into multiple parts. If at some time in the
future, i128 becomes a legal type, this code can be removed again.

This fixes PR26559.

llvm-svn: 261325

show more ...

[SystemZ] Support large LLVM IR struct return values

Recent mesa/llvmpipe crashes on SystemZ due to a failed assertion when
attempting to compile a routine with a return type of
{ <4 x float>, <4

[SystemZ] Support large LLVM IR struct return values

Recent mesa/llvmpipe crashes on SystemZ due to a failed assertion when
attempting to compile a routine with a return type of
{ <4 x float>, <4 x float>, <4 x float>, <4 x float> }
on a system without vector instruction support.

This is because after legalizing the vector type, we get a return value
consisting of 16 floats, which cannot all be returned in registers.

Usually, what should happen in this case is that the target's CanLowerReturn
routine rejects the return type, in which case SelectionDAG falls back to
implementing a structure return in memory via implicit reference.

However, the SystemZ target never actually implemented any CanLowerReturn
routine, and thus would accept any struct return type.

This patch fixes the crash by implementing CanLowerReturn. As a side effect,
this also handles fp128 return values, fixing a todo that was noted in
SystemZCallingConv.td.

llvm-svn: 244889

show more ...

[SystemZ] Handle sub-128 vectors

The ABI allows sub-128 vectors to be passed and returned in registers,
with the vector occupying the upper part of a register. We therefore
want to legalize those t

[SystemZ] Handle sub-128 vectors

The ABI allows sub-128 vectors to be passed and returned in registers,
with the vector occupying the upper part of a register. We therefore
want to legalize those types by widening the vector rather than promoting
the elements.

The patch includes some simple tests for sub-128 vectors and also tests
that we can recognize various pack sequences, some of which use sub-128
vectors as temporary results. One of these forms is based on the pack
sequences generated by llvmpipe when no intrinsics are used.

Signed unpacks are recognized as BUILD_VECTORs whose elements are
individually sign-extended. Unsigned unpacks can have the equivalent
form with zero extension, but they also occur as shuffles in which some
elements are zero.

Based on a patch by Richard Sandiford.

llvm-svn: 236525

show more ...

[SystemZ] Add CodeGen support for v4f32

The architecture doesn't really have any native v4f32 operations except
v4f32->v2f64 and v2f64->v4f32 conversions, with only half of the v4f32
elements being

[SystemZ] Add CodeGen support for v4f32

The architecture doesn't really have any native v4f32 operations except
v4f32->v2f64 and v2f64->v4f32 conversions, with only half of the v4f32
elements being used. Even so, using vector registers for <4 x float>
and scalarising individual operations is much better than generating
completely scalar code, since there's much less register pressure.
It's also more efficient to do v4f32 comparisons by extending to 2
v2f64s, comparing those, then packing the result.

This particularly helps with llvmpipe.

Based on a patch by Richard Sandiford.

llvm-svn: 236523

show more ...

[SystemZ] Add CodeGen support for v2f64

This adds ABI and CodeGen support for the v2f64 type, which is natively
supported by z13 instructions.

Based on a patch by Richard Sandiford.

llvm-svn: 2365

[SystemZ] Add CodeGen support for v2f64

This adds ABI and CodeGen support for the v2f64 type, which is natively
supported by z13 instructions.

Based on a patch by Richard Sandiford.

llvm-svn: 236522

show more ...

[SystemZ] Add CodeGen support for integer vector types

This the first of a series of patches to add CodeGen support exploiting
the instructions of the z13 vector facility. This patch adds support
f

[SystemZ] Add CodeGen support for integer vector types

This the first of a series of patches to add CodeGen support exploiting
the instructions of the z13 vector facility. This patch adds support
for the native integer vector types (v16i8, v8i16, v4i32, v2i64).

When the vector facility is present, we default to the new vector ABI.
This is characterized by two major differences:
- Vector types are passed/returned in vector registers
(except for unnamed arguments of a variable-argument list function).
- Vector types are at most 8-byte aligned.

The reason for the choice of 8-byte vector alignment is that the hardware
is able to efficiently load vectors at 8-byte alignment, and the ABI only
guarantees 8-byte alignment of the stack pointer, so requiring any higher
alignment for vectors would require dynamic stack re-alignment code.

However, for compatibility with old code that may use vector types, when
*not* using the vector facility, the old alignment rules (vector types
are naturally aligned) remain in use.

These alignment rules are not only implemented at the C language level
(implemented in clang), but also at the LLVM IR level. This is done
by selecting a different DataLayout string depending on whether the
vector ABI is in effect or not.

Based on a patch by Richard Sandiford.

llvm-svn: 236521

show more ...

[SystemZ] Use SystemZCallingConv.td to define callee-saved registers

Just a clean-up. No behavioral change intended.

llvm-svn: 212711

[SystemZ] Rename 32-bit GPR registers

I'm about to add support for high-word operations, so it seemed better
for the low-word registers to have names like R0L rather than R0W.
No behavioral change i

[SystemZ] Rename 32-bit GPR registers

I'm about to add support for high-word operations, so it seemed better
for the low-word registers to have names like R0L rather than R0W.
No behavioral change intended.

llvm-svn: 191655

show more ...