1; Test the handling of i128 argument values 2; 3; RUN: llc < %s -mtriple=s390x-linux-gnu | FileCheck %s -check-prefix=CHECK-INT 4; RUN: llc < %s -mtriple=s390x-linux-gnu | FileCheck %s -check-prefix=CHECK-I128-1 5; RUN: llc < %s -mtriple=s390x-linux-gnu | FileCheck %s -check-prefix=CHECK-I128-2 6; RUN: llc < %s -mtriple=s390x-linux-gnu | FileCheck %s -check-prefix=CHECK-STACK 7 8declare void @bar(i64, i64, i64, i64, i128, 9 i64, i64, i64, i64, i128) 10 11; There are two indirect i128 slots, one at offset 200 (the first available 12; byte after the outgoing arguments) and one immediately after it at 216. 13; These slots should be set up outside the glued call sequence, so would 14; normally use %f0/%f2 as the first available 128-bit pair. This choice 15; is hard-coded in the I128 tests. 16; 17; The order of the CHECK-STACK stores doesn't matter. It would be OK to reorder 18; them in response to future code changes. 19define void @foo() { 20; CHECK-INT-LABEL: foo: 21; CHECK-INT-DAG: lghi %r2, 1 22; CHECK-INT-DAG: lghi %r3, 2 23; CHECK-INT-DAG: lghi %r4, 3 24; CHECK-INT-DAG: lghi %r5, 4 25; CHECK-INT-DAG: la %r6, {{200|216}}(%r15) 26; CHECK-INT: brasl %r14, bar@PLT 27; 28; CHECK-I128-1-LABEL: foo: 29; CHECK-I128-1: aghi %r15, -232 30; CHECK-I128-1-DAG: mvghi 200(%r15), 0 31; CHECK-I128-1-DAG: mvghi 208(%r15), 0 32; CHECK-I128-1: brasl %r14, bar@PLT 33; 34; CHECK-I128-2-LABEL: foo: 35; CHECK-I128-2: aghi %r15, -232 36; CHECK-I128-2-DAG: mvghi 216(%r15), 0 37; CHECK-I128-2-DAG: mvghi 224(%r15), 0 38; CHECK-I128-2: brasl %r14, bar@PLT 39; 40; CHECK-STACK-LABEL: foo: 41; CHECK-STACK: aghi %r15, -232 42; CHECK-STACK: la [[REGISTER:%r[0-5]+]], {{200|216}}(%r15) 43; CHECK-STACK: stg [[REGISTER]], 192(%r15) 44; CHECK-STACK: mvghi 184(%r15), 8 45; CHECK-STACK: mvghi 176(%r15), 7 46; CHECK-STACK: mvghi 168(%r15), 6 47; CHECK-STACK: mvghi 160(%r15), 5 48; CHECK-STACK: brasl %r14, bar@PLT 49 50 call void @bar (i64 1, i64 2, i64 3, i64 4, i128 0, 51 i64 5, i64 6, i64 7, i64 8, i128 0) 52 ret void 53} 54