llvm/test/CodeGen/SystemZ/args-09.ll
Ulrich Weigand c80aad901b [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.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261325 91177308-0d34-0410-b5e6-96231b3b80d8
2016-02-19 14:10:21 +00:00

54 lines
1.9 KiB
LLVM

; Test the handling of i128 argument values
;
; RUN: llc < %s -mtriple=s390x-linux-gnu | FileCheck %s -check-prefix=CHECK-INT
; RUN: llc < %s -mtriple=s390x-linux-gnu | FileCheck %s -check-prefix=CHECK-I128-1
; RUN: llc < %s -mtriple=s390x-linux-gnu | FileCheck %s -check-prefix=CHECK-I128-2
; RUN: llc < %s -mtriple=s390x-linux-gnu | FileCheck %s -check-prefix=CHECK-STACK
declare void @bar(i64, i64, i64, i64, i128,
i64, i64, i64, i64, i128)
; There are two indirect i128 slots, one at offset 200 (the first available
; byte after the outgoing arguments) and one immediately after it at 216.
; These slots should be set up outside the glued call sequence, so would
; normally use %f0/%f2 as the first available 128-bit pair. This choice
; is hard-coded in the I128 tests.
;
; The order of the CHECK-STACK stores doesn't matter. It would be OK to reorder
; them in response to future code changes.
define void @foo() {
; CHECK-INT-LABEL: foo:
; CHECK-INT-DAG: lghi %r2, 1
; CHECK-INT-DAG: lghi %r3, 2
; CHECK-INT-DAG: lghi %r4, 3
; CHECK-INT-DAG: lghi %r5, 4
; CHECK-INT-DAG: la %r6, {{200|216}}(%r15)
; CHECK-INT: brasl %r14, bar@PLT
;
; CHECK-I128-1-LABEL: foo:
; CHECK-I128-1: aghi %r15, -232
; CHECK-I128-1-DAG: mvghi 200(%r15), 0
; CHECK-I128-1-DAG: mvghi 208(%r15), 0
; CHECK-I128-1: brasl %r14, bar@PLT
;
; CHECK-I128-2-LABEL: foo:
; CHECK-I128-2: aghi %r15, -232
; CHECK-I128-2-DAG: mvghi 216(%r15), 0
; CHECK-I128-2-DAG: mvghi 224(%r15), 0
; CHECK-I128-2: brasl %r14, bar@PLT
;
; CHECK-STACK-LABEL: foo:
; CHECK-STACK: aghi %r15, -232
; CHECK-STACK: la [[REGISTER:%r[0-5]+]], {{200|216}}(%r15)
; CHECK-STACK: stg [[REGISTER]], 192(%r15)
; CHECK-STACK: mvghi 184(%r15), 8
; CHECK-STACK: mvghi 176(%r15), 7
; CHECK-STACK: mvghi 168(%r15), 6
; CHECK-STACK: mvghi 160(%r15), 5
; CHECK-STACK: brasl %r14, bar@PLT
call void @bar (i64 1, i64 2, i64 3, i64 4, i128 0,
i64 5, i64 6, i64 7, i64 8, i128 0)
ret void
}