2017-08-02 06:20:41 +08:00
|
|
|
; RUN: llc -verify-machineinstrs < %s -mcpu=pwr8 \
|
2016-10-04 19:25:52 +08:00
|
|
|
; RUN: -mattr=+altivec -mattr=-vsx | FileCheck %s
|
2017-08-02 06:20:41 +08:00
|
|
|
; RUN: llc -verify-machineinstrs < %s -mattr=+altivec \
|
2016-10-04 19:25:52 +08:00
|
|
|
; RUN: -mattr=-vsx | FileCheck %s
|
2017-08-02 06:20:41 +08:00
|
|
|
; RUN: llc -verify-machineinstrs < %s -mcpu=pwr9 \
|
2016-10-04 19:25:52 +08:00
|
|
|
; RUN: -mattr=-direct-move -mattr=+altivec | FileCheck %s
|
[PowerPC 1/4] Little-endian adjustments for VSX loads/stores
This patch addresses the inherent big-endian bias in the lxvd2x,
lxvw4x, stxvd2x, and stxvw4x instructions. These instructions load
vector elements into registers left-to-right (with the first element
loaded into the high-order bits of the register), regardless of the
endian setting of the processor. However, these are the only
vector memory instructions that permit unaligned storage accesses, so
we want to use them for little-endian.
To make this work, a lxvd2x or lxvw4x is replaced with an lxvd2x
followed by an xxswapd, which swaps the doublewords. This works for
lxvw4x as well as lxvd2x, because for lxvw4x on an LE system the
vector elements are in LE order (right-to-left) within each
doubleword. (Thus after lxvw2x of a <4 x float> the elements will
appear as 1, 0, 3, 2. Following the swap, they will appear as 3, 2,
0, 1, as desired.) For stores, an stxvd2x or stxvw4x is replaced
with an stxvd2x preceded by an xxswapd.
Introduction of extra swap instructions provides correctness, but
obviously is not ideal from a performance perspective. Future patches
will address this with optimizations to remove most of the introduced
swaps, which have proven effective in other implementations.
The introduction of the swaps is performed during lowering of LOAD,
STORE, INTRINSIC_W_CHAIN, and INTRINSIC_VOID operations. The latter
are used to translate intrinsics that specify the VSX loads and stores
directly into equivalent sequences for little endian. Thus code that
uses vec_vsx_ld and vec_vsx_st does not have to be modified to be
ported from BE to LE.
We introduce new PPCISD opcodes for LXVD2X, STXVD2X, and XXSWAPD for
use during this lowering step. In PPCInstrVSX.td, we add new SDType
and SDNode definitions for these (PPClxvd2x, PPCstxvd2x, PPCxxswapd).
These are recognized during instruction selection and mapped to the
correct instructions.
Several tests that were written to use -mcpu=pwr7 or pwr8 are modified
to disable VSX on LE variants because code generation changes with
this and subsequent patches in this set. I chose to include all of
these in the first patch than try to rigorously sort out which tests
were broken by one or another of the patches. Sorry about that.
The new test vsx-ldst-builtin-le.ll, and the changes to vsx-ldst.ll,
are disabled until LE support is enabled because of breakages that
occur as noted in those tests. They are re-enabled in patch 4/4.
llvm-svn: 223783
2014-12-10 00:35:51 +08:00
|
|
|
|
|
|
|
; Currently VSX support is disabled for this test because we generate lxsdx
|
|
|
|
; instead of lfd, and stxsdx instead of stfd. That is a poor choice when we
|
|
|
|
; have reg+imm addressing, and is on the list of things to be fixed.
|
2015-01-29 23:59:09 +08:00
|
|
|
; The second run step is to ensure that -march=ppc64le is adequate to select
|
|
|
|
; the same feature set as with -mcpu=pwr8 since that is the baseline for ppc64le.
|
[PowerPC] ELFv2 aggregate passing support
This patch adds infrastructure support for passing array types
directly. These can be used by the front-end to pass aggregate
types (coerced to an appropriate array type). The details of the
array type being used inform the back-end about ABI-relevant
properties. Specifically, the array element type encodes:
- whether the parameter should be passed in FPRs, VRs, or just
GPRs/stack slots (for float / vector / integer element types,
respectively)
- what the alignment requirements of the parameter are when passed in
GPRs/stack slots (8 for float / 16 for vector / the element type
size for integer element types) -- this corresponds to the
"byval align" field
Using the infrastructure provided by this patch, a companion patch
to clang will enable two features:
- In the ELFv2 ABI, pass (and return) "homogeneous" floating-point
or vector aggregates in FPRs and VRs (this is similar to the ARM
homogeneous aggregate ABI)
- As an optimization for both ELFv1 and ELFv2 ABIs, pass aggregates
that fit fully in registers without using the "byval" mechanism
The patch uses the functionArgumentNeedsConsecutiveRegisters callback
to encode that special treatment is required for all directly-passed
array types. The isInConsecutiveRegs / isInConsecutiveRegsLast bits set
as a results are then used to implement the required size and alignment
rules in CalculateStackSlotSize / CalculateStackSlotAlignment etc.
As a related change, the ABI routines have to be modified to support
passing floating-point types in GPRs. This is necessary because with
homogeneous aggregates of 4-byte float type we can now run out of FPRs
*before* we run out of the 64-byte argument save area that is shadowed
by GPRs. Any extra floating-point arguments that no longer fit in FPRs
must now be passed in GPRs until we run out of those too.
Note that there was already code to pass floating-point arguments in
GPRs used with vararg parameters, which was done by writing the argument
out to the argument save area first and then reloading into GPRs. The
patch re-implements this, however, in favor of code packing float arguments
directly via extension/truncation, BITCAST, and BUILD_PAIR operations.
This is required to support the ELFv2 ABI, since we cannot unconditionally
write to the argument save area (which the caller might not have allocated).
The change does, however, affect ELFv1 varags routines too; but even here
the overall effect should be advantageous: Instead of loading the argument
into the FPR, then storing the argument to the stack slot, and finally
reloading the argument from the stack slot into a GPR, the new code now
just loads the argument into the FPR, and subsequently loads the argument
into the GPR (via BITCAST). That BITCAST might imply a save/reload from
a stack temporary (in which case we're no worse than before); but it
might be implemented more efficiently in some cases.
The final part of the patch enables up to 8 FPRs and VRs for argument
return in PPCCallingConv.td; this is required to support returning
ELFv2 homogeneous aggregates. (Note that this doesn't affect other ABIs
since LLVM wil only look for which register to use if the parameter is
marked as "direct" return anyway.)
Reviewed by Hal Finkel.
llvm-svn: 213493
2014-07-21 08:13:26 +08:00
|
|
|
|
|
|
|
target datalayout = "e-m:e-i64:64-n32:64"
|
|
|
|
target triple = "powerpc64le-unknown-linux-gnu"
|
|
|
|
|
|
|
|
;
|
|
|
|
; Verify use of registers for float/vector aggregate return.
|
|
|
|
;
|
|
|
|
|
|
|
|
define [8 x float] @return_float([8 x float] %x) {
|
|
|
|
entry:
|
|
|
|
ret [8 x float] %x
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @return_float
|
|
|
|
; CHECK: %entry
|
|
|
|
; CHECK-NEXT: blr
|
|
|
|
|
|
|
|
define [8 x double] @return_double([8 x double] %x) {
|
|
|
|
entry:
|
|
|
|
ret [8 x double] %x
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @return_double
|
|
|
|
; CHECK: %entry
|
|
|
|
; CHECK-NEXT: blr
|
|
|
|
|
|
|
|
define [4 x ppc_fp128] @return_ppcf128([4 x ppc_fp128] %x) {
|
|
|
|
entry:
|
|
|
|
ret [4 x ppc_fp128] %x
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @return_ppcf128
|
|
|
|
; CHECK: %entry
|
|
|
|
; CHECK-NEXT: blr
|
|
|
|
|
|
|
|
define [8 x <4 x i32>] @return_v4i32([8 x <4 x i32>] %x) {
|
|
|
|
entry:
|
|
|
|
ret [8 x <4 x i32>] %x
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @return_v4i32
|
|
|
|
; CHECK: %entry
|
|
|
|
; CHECK-NEXT: blr
|
|
|
|
|
|
|
|
|
|
|
|
;
|
|
|
|
; Verify amount of space taken up by aggregates in the parameter save area.
|
|
|
|
;
|
|
|
|
|
|
|
|
define i64 @callee_float([7 x float] %a, [7 x float] %b, i64 %c) {
|
|
|
|
entry:
|
|
|
|
ret i64 %c
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @callee_float
|
|
|
|
; CHECK: ld 3, 96(1)
|
|
|
|
; CHECK: blr
|
|
|
|
|
|
|
|
define void @caller_float(i64 %x, [7 x float] %y) {
|
|
|
|
entry:
|
|
|
|
tail call void @test_float([7 x float] %y, [7 x float] %y, i64 %x)
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @caller_float
|
|
|
|
; CHECK: std 3, 96(1)
|
|
|
|
; CHECK: bl test_float
|
|
|
|
|
|
|
|
declare void @test_float([7 x float], [7 x float], i64)
|
|
|
|
|
|
|
|
define i64 @callee_double(i64 %a, [7 x double] %b, i64 %c) {
|
|
|
|
entry:
|
|
|
|
ret i64 %c
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @callee_double
|
|
|
|
; CHECK: ld 3, 96(1)
|
|
|
|
; CHECK: blr
|
|
|
|
|
|
|
|
define void @caller_double(i64 %x, [7 x double] %y) {
|
|
|
|
entry:
|
|
|
|
tail call void @test_double(i64 %x, [7 x double] %y, i64 %x)
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @caller_double
|
|
|
|
; CHECK: std 3, 96(1)
|
|
|
|
; CHECK: bl test_double
|
|
|
|
|
|
|
|
declare void @test_double(i64, [7 x double], i64)
|
|
|
|
|
|
|
|
define i64 @callee_ppcf128(i64 %a, [4 x ppc_fp128] %b, i64 %c) {
|
|
|
|
entry:
|
|
|
|
ret i64 %c
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @callee_ppcf128
|
|
|
|
; CHECK: ld 3, 104(1)
|
|
|
|
; CHECK: blr
|
|
|
|
|
|
|
|
define void @caller_ppcf128(i64 %x, [4 x ppc_fp128] %y) {
|
|
|
|
entry:
|
|
|
|
tail call void @test_ppcf128(i64 %x, [4 x ppc_fp128] %y, i64 %x)
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @caller_ppcf128
|
|
|
|
; CHECK: std 3, 104(1)
|
|
|
|
; CHECK: bl test_ppcf128
|
|
|
|
|
|
|
|
declare void @test_ppcf128(i64, [4 x ppc_fp128], i64)
|
|
|
|
|
|
|
|
define i64 @callee_i64(i64 %a, [7 x i64] %b, i64 %c) {
|
|
|
|
entry:
|
|
|
|
ret i64 %c
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @callee_i64
|
|
|
|
; CHECK: ld 3, 96(1)
|
|
|
|
; CHECK: blr
|
|
|
|
|
|
|
|
define void @caller_i64(i64 %x, [7 x i64] %y) {
|
|
|
|
entry:
|
|
|
|
tail call void @test_i64(i64 %x, [7 x i64] %y, i64 %x)
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @caller_i64
|
|
|
|
; CHECK: std 3, 96(1)
|
|
|
|
; CHECK: bl test_i64
|
|
|
|
|
|
|
|
declare void @test_i64(i64, [7 x i64], i64)
|
|
|
|
|
|
|
|
define i64 @callee_i128(i64 %a, [4 x i128] %b, i64 %c) {
|
|
|
|
entry:
|
|
|
|
ret i64 %c
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @callee_i128
|
|
|
|
; CHECK: ld 3, 112(1)
|
|
|
|
; CHECK: blr
|
|
|
|
|
|
|
|
define void @caller_i128(i64 %x, [4 x i128] %y) {
|
|
|
|
entry:
|
|
|
|
tail call void @test_i128(i64 %x, [4 x i128] %y, i64 %x)
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @caller_i128
|
|
|
|
; CHECK: std 3, 112(1)
|
|
|
|
; CHECK: bl test_i128
|
|
|
|
|
|
|
|
declare void @test_i128(i64, [4 x i128], i64)
|
|
|
|
|
|
|
|
define i64 @callee_v4i32(i64 %a, [4 x <4 x i32>] %b, i64 %c) {
|
|
|
|
entry:
|
|
|
|
ret i64 %c
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @callee_v4i32
|
|
|
|
; CHECK: ld 3, 112(1)
|
|
|
|
; CHECK: blr
|
|
|
|
|
|
|
|
define void @caller_v4i32(i64 %x, [4 x <4 x i32>] %y) {
|
|
|
|
entry:
|
|
|
|
tail call void @test_v4i32(i64 %x, [4 x <4 x i32>] %y, i64 %x)
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @caller_v4i32
|
|
|
|
; CHECK: std 3, 112(1)
|
|
|
|
; CHECK: bl test_v4i32
|
|
|
|
|
|
|
|
declare void @test_v4i32(i64, [4 x <4 x i32>], i64)
|
|
|
|
|
|
|
|
|
|
|
|
;
|
|
|
|
; Verify handling of floating point arguments in GPRs
|
|
|
|
;
|
|
|
|
|
|
|
|
%struct.float8 = type { [8 x float] }
|
|
|
|
%struct.float5 = type { [5 x float] }
|
|
|
|
%struct.float2 = type { [2 x float] }
|
|
|
|
|
|
|
|
@g8 = common global %struct.float8 zeroinitializer, align 4
|
|
|
|
@g5 = common global %struct.float5 zeroinitializer, align 4
|
|
|
|
@g2 = common global %struct.float2 zeroinitializer, align 4
|
|
|
|
|
|
|
|
define float @callee0([7 x float] %a, [7 x float] %b) {
|
|
|
|
entry:
|
|
|
|
%b.extract = extractvalue [7 x float] %b, 6
|
|
|
|
ret float %b.extract
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @callee0
|
|
|
|
; CHECK: stw 10, [[OFF:.*]](1)
|
|
|
|
; CHECK: lfs 1, [[OFF]](1)
|
|
|
|
; CHECK: blr
|
|
|
|
|
|
|
|
define void @caller0([7 x float] %a) {
|
|
|
|
entry:
|
|
|
|
tail call void @test0([7 x float] %a, [7 x float] %a)
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @caller0
|
|
|
|
; CHECK-DAG: fmr 8, 1
|
|
|
|
; CHECK-DAG: fmr 9, 2
|
|
|
|
; CHECK-DAG: fmr 10, 3
|
|
|
|
; CHECK-DAG: fmr 11, 4
|
|
|
|
; CHECK-DAG: fmr 12, 5
|
|
|
|
; CHECK-DAG: fmr 13, 6
|
|
|
|
; CHECK-DAG: stfs 7, [[OFF:[0-9]+]](1)
|
|
|
|
; CHECK-DAG: lwz 10, [[OFF]](1)
|
|
|
|
; CHECK: bl test0
|
|
|
|
|
|
|
|
declare void @test0([7 x float], [7 x float])
|
|
|
|
|
|
|
|
define float @callee1([8 x float] %a, [8 x float] %b) {
|
|
|
|
entry:
|
|
|
|
%b.extract = extractvalue [8 x float] %b, 7
|
|
|
|
ret float %b.extract
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @callee1
|
|
|
|
; CHECK: rldicl [[REG:[0-9]+]], 10, 32, 32
|
|
|
|
; CHECK: stw [[REG]], [[OFF:.*]](1)
|
|
|
|
; CHECK: lfs 1, [[OFF]](1)
|
|
|
|
; CHECK: blr
|
|
|
|
|
|
|
|
define void @caller1([8 x float] %a) {
|
|
|
|
entry:
|
|
|
|
tail call void @test1([8 x float] %a, [8 x float] %a)
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @caller1
|
|
|
|
; CHECK-DAG: fmr 9, 1
|
|
|
|
; CHECK-DAG: fmr 10, 2
|
|
|
|
; CHECK-DAG: fmr 11, 3
|
|
|
|
; CHECK-DAG: fmr 12, 4
|
|
|
|
; CHECK-DAG: fmr 13, 5
|
|
|
|
; CHECK-DAG: stfs 5, [[OFF0:[0-9]+]](1)
|
|
|
|
; CHECK-DAG: stfs 6, [[OFF1:[0-9]+]](1)
|
|
|
|
; CHECK-DAG: stfs 7, [[OFF2:[0-9]+]](1)
|
|
|
|
; CHECK-DAG: stfs 8, [[OFF3:[0-9]+]](1)
|
|
|
|
; CHECK-DAG: lwz [[REG0:[0-9]+]], [[OFF0]](1)
|
|
|
|
; CHECK-DAG: lwz [[REG1:[0-9]+]], [[OFF1]](1)
|
|
|
|
; CHECK-DAG: lwz [[REG2:[0-9]+]], [[OFF2]](1)
|
|
|
|
; CHECK-DAG: lwz [[REG3:[0-9]+]], [[OFF3]](1)
|
|
|
|
; CHECK-DAG: sldi [[REG1]], [[REG1]], 32
|
|
|
|
; CHECK-DAG: sldi [[REG3]], [[REG3]], 32
|
|
|
|
; CHECK-DAG: or 9, [[REG0]], [[REG1]]
|
|
|
|
; CHECK-DAG: or 10, [[REG2]], [[REG3]]
|
|
|
|
; CHECK: bl test1
|
|
|
|
|
|
|
|
declare void @test1([8 x float], [8 x float])
|
|
|
|
|
|
|
|
define float @callee2([8 x float] %a, [5 x float] %b, [2 x float] %c) {
|
|
|
|
entry:
|
|
|
|
%c.extract = extractvalue [2 x float] %c, 1
|
|
|
|
ret float %c.extract
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @callee2
|
|
|
|
; CHECK: rldicl [[REG:[0-9]+]], 10, 32, 32
|
|
|
|
; CHECK: stw [[REG]], [[OFF:.*]](1)
|
|
|
|
; CHECK: lfs 1, [[OFF]](1)
|
|
|
|
; CHECK: blr
|
|
|
|
|
|
|
|
define void @caller2() {
|
|
|
|
entry:
|
2015-03-14 02:20:45 +08:00
|
|
|
%0 = load [8 x float], [8 x float]* getelementptr inbounds (%struct.float8, %struct.float8* @g8, i64 0, i32 0), align 4
|
|
|
|
%1 = load [5 x float], [5 x float]* getelementptr inbounds (%struct.float5, %struct.float5* @g5, i64 0, i32 0), align 4
|
|
|
|
%2 = load [2 x float], [2 x float]* getelementptr inbounds (%struct.float2, %struct.float2* @g2, i64 0, i32 0), align 4
|
[PowerPC] ELFv2 aggregate passing support
This patch adds infrastructure support for passing array types
directly. These can be used by the front-end to pass aggregate
types (coerced to an appropriate array type). The details of the
array type being used inform the back-end about ABI-relevant
properties. Specifically, the array element type encodes:
- whether the parameter should be passed in FPRs, VRs, or just
GPRs/stack slots (for float / vector / integer element types,
respectively)
- what the alignment requirements of the parameter are when passed in
GPRs/stack slots (8 for float / 16 for vector / the element type
size for integer element types) -- this corresponds to the
"byval align" field
Using the infrastructure provided by this patch, a companion patch
to clang will enable two features:
- In the ELFv2 ABI, pass (and return) "homogeneous" floating-point
or vector aggregates in FPRs and VRs (this is similar to the ARM
homogeneous aggregate ABI)
- As an optimization for both ELFv1 and ELFv2 ABIs, pass aggregates
that fit fully in registers without using the "byval" mechanism
The patch uses the functionArgumentNeedsConsecutiveRegisters callback
to encode that special treatment is required for all directly-passed
array types. The isInConsecutiveRegs / isInConsecutiveRegsLast bits set
as a results are then used to implement the required size and alignment
rules in CalculateStackSlotSize / CalculateStackSlotAlignment etc.
As a related change, the ABI routines have to be modified to support
passing floating-point types in GPRs. This is necessary because with
homogeneous aggregates of 4-byte float type we can now run out of FPRs
*before* we run out of the 64-byte argument save area that is shadowed
by GPRs. Any extra floating-point arguments that no longer fit in FPRs
must now be passed in GPRs until we run out of those too.
Note that there was already code to pass floating-point arguments in
GPRs used with vararg parameters, which was done by writing the argument
out to the argument save area first and then reloading into GPRs. The
patch re-implements this, however, in favor of code packing float arguments
directly via extension/truncation, BITCAST, and BUILD_PAIR operations.
This is required to support the ELFv2 ABI, since we cannot unconditionally
write to the argument save area (which the caller might not have allocated).
The change does, however, affect ELFv1 varags routines too; but even here
the overall effect should be advantageous: Instead of loading the argument
into the FPR, then storing the argument to the stack slot, and finally
reloading the argument from the stack slot into a GPR, the new code now
just loads the argument into the FPR, and subsequently loads the argument
into the GPR (via BITCAST). That BITCAST might imply a save/reload from
a stack temporary (in which case we're no worse than before); but it
might be implemented more efficiently in some cases.
The final part of the patch enables up to 8 FPRs and VRs for argument
return in PPCCallingConv.td; this is required to support returning
ELFv2 homogeneous aggregates. (Note that this doesn't affect other ABIs
since LLVM wil only look for which register to use if the parameter is
marked as "direct" return anyway.)
Reviewed by Hal Finkel.
llvm-svn: 213493
2014-07-21 08:13:26 +08:00
|
|
|
tail call void @test2([8 x float] %0, [5 x float] %1, [2 x float] %2)
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @caller2
|
[PowerPC] Make LDtocL and friends invariant loads
LDtocL, and other loads that roughly correspond to the TOC_ENTRY SDAG node,
represent loads from the TOC, which is invariant. As a result, these loads can
be hoisted out of loops, etc. In order to do this, we need to generate
GOT-style MMOs for TOC_ENTRY, which requires treating it as a legitimate memory
intrinsic node type. Once this is done, the MMO transfer is automatically
handled for TableGen-driven instruction selection, and for nodes generated
directly in PPCISelDAGToDAG, we need to transfer the MMOs manually.
Also, we were not transferring MMOs associated with pre-increment loads, so do
that too.
Lastly, this fixes an exposed bug where R30 was not added as a defined operand of
UpdateGBR.
This problem was highlighted by an example (used to generate the test case)
posted to llvmdev by Francois Pichet.
llvm-svn: 230553
2015-02-26 05:36:59 +08:00
|
|
|
; CHECK: ld {{[0-9]+}}, .LC
|
|
|
|
; CHECK-DAG: lfs 1, 0({{[0-9]+}})
|
|
|
|
; CHECK-DAG: lfs 2, 4({{[0-9]+}})
|
|
|
|
; CHECK-DAG: lfs 3, 8({{[0-9]+}})
|
|
|
|
; CHECK-DAG: lfs 4, 12({{[0-9]+}})
|
|
|
|
; CHECK-DAG: lfs 5, 16({{[0-9]+}})
|
|
|
|
; CHECK-DAG: lfs 6, 20({{[0-9]+}})
|
|
|
|
; CHECK-DAG: lfs 7, 24({{[0-9]+}})
|
|
|
|
; CHECK-DAG: lfs 8, 28({{[0-9]+}})
|
|
|
|
|
|
|
|
; CHECK-DAG: lfs 9, 0({{[0-9]+}})
|
|
|
|
; CHECK-DAG: lfs 10, 4({{[0-9]+}})
|
|
|
|
; CHECK-DAG: lfs 11, 8({{[0-9]+}})
|
|
|
|
; CHECK-DAG: lfs 12, 12({{[0-9]+}})
|
|
|
|
; CHECK-DAG: lfs 13, 16({{[0-9]+}})
|
|
|
|
|
2017-03-02 02:12:29 +08:00
|
|
|
; CHECK-DAG: ld 10, 0({{[0-9]+}})
|
[PowerPC] ELFv2 aggregate passing support
This patch adds infrastructure support for passing array types
directly. These can be used by the front-end to pass aggregate
types (coerced to an appropriate array type). The details of the
array type being used inform the back-end about ABI-relevant
properties. Specifically, the array element type encodes:
- whether the parameter should be passed in FPRs, VRs, or just
GPRs/stack slots (for float / vector / integer element types,
respectively)
- what the alignment requirements of the parameter are when passed in
GPRs/stack slots (8 for float / 16 for vector / the element type
size for integer element types) -- this corresponds to the
"byval align" field
Using the infrastructure provided by this patch, a companion patch
to clang will enable two features:
- In the ELFv2 ABI, pass (and return) "homogeneous" floating-point
or vector aggregates in FPRs and VRs (this is similar to the ARM
homogeneous aggregate ABI)
- As an optimization for both ELFv1 and ELFv2 ABIs, pass aggregates
that fit fully in registers without using the "byval" mechanism
The patch uses the functionArgumentNeedsConsecutiveRegisters callback
to encode that special treatment is required for all directly-passed
array types. The isInConsecutiveRegs / isInConsecutiveRegsLast bits set
as a results are then used to implement the required size and alignment
rules in CalculateStackSlotSize / CalculateStackSlotAlignment etc.
As a related change, the ABI routines have to be modified to support
passing floating-point types in GPRs. This is necessary because with
homogeneous aggregates of 4-byte float type we can now run out of FPRs
*before* we run out of the 64-byte argument save area that is shadowed
by GPRs. Any extra floating-point arguments that no longer fit in FPRs
must now be passed in GPRs until we run out of those too.
Note that there was already code to pass floating-point arguments in
GPRs used with vararg parameters, which was done by writing the argument
out to the argument save area first and then reloading into GPRs. The
patch re-implements this, however, in favor of code packing float arguments
directly via extension/truncation, BITCAST, and BUILD_PAIR operations.
This is required to support the ELFv2 ABI, since we cannot unconditionally
write to the argument save area (which the caller might not have allocated).
The change does, however, affect ELFv1 varags routines too; but even here
the overall effect should be advantageous: Instead of loading the argument
into the FPR, then storing the argument to the stack slot, and finally
reloading the argument from the stack slot into a GPR, the new code now
just loads the argument into the FPR, and subsequently loads the argument
into the GPR (via BITCAST). That BITCAST might imply a save/reload from
a stack temporary (in which case we're no worse than before); but it
might be implemented more efficiently in some cases.
The final part of the patch enables up to 8 FPRs and VRs for argument
return in PPCCallingConv.td; this is required to support returning
ELFv2 homogeneous aggregates. (Note that this doesn't affect other ABIs
since LLVM wil only look for which register to use if the parameter is
marked as "direct" return anyway.)
Reviewed by Hal Finkel.
llvm-svn: 213493
2014-07-21 08:13:26 +08:00
|
|
|
; CHECK: bl test2
|
|
|
|
|
|
|
|
declare void @test2([8 x float], [5 x float], [2 x float])
|
|
|
|
|
|
|
|
define double @callee3([8 x float] %a, [5 x float] %b, double %c) {
|
|
|
|
entry:
|
|
|
|
ret double %c
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @callee3
|
|
|
|
; CHECK: std 10, [[OFF:.*]](1)
|
|
|
|
; CHECK: lfd 1, [[OFF]](1)
|
|
|
|
; CHECK: blr
|
|
|
|
|
|
|
|
define void @caller3(double %d) {
|
|
|
|
entry:
|
2015-03-14 02:20:45 +08:00
|
|
|
%0 = load [8 x float], [8 x float]* getelementptr inbounds (%struct.float8, %struct.float8* @g8, i64 0, i32 0), align 4
|
|
|
|
%1 = load [5 x float], [5 x float]* getelementptr inbounds (%struct.float5, %struct.float5* @g5, i64 0, i32 0), align 4
|
[PowerPC] ELFv2 aggregate passing support
This patch adds infrastructure support for passing array types
directly. These can be used by the front-end to pass aggregate
types (coerced to an appropriate array type). The details of the
array type being used inform the back-end about ABI-relevant
properties. Specifically, the array element type encodes:
- whether the parameter should be passed in FPRs, VRs, or just
GPRs/stack slots (for float / vector / integer element types,
respectively)
- what the alignment requirements of the parameter are when passed in
GPRs/stack slots (8 for float / 16 for vector / the element type
size for integer element types) -- this corresponds to the
"byval align" field
Using the infrastructure provided by this patch, a companion patch
to clang will enable two features:
- In the ELFv2 ABI, pass (and return) "homogeneous" floating-point
or vector aggregates in FPRs and VRs (this is similar to the ARM
homogeneous aggregate ABI)
- As an optimization for both ELFv1 and ELFv2 ABIs, pass aggregates
that fit fully in registers without using the "byval" mechanism
The patch uses the functionArgumentNeedsConsecutiveRegisters callback
to encode that special treatment is required for all directly-passed
array types. The isInConsecutiveRegs / isInConsecutiveRegsLast bits set
as a results are then used to implement the required size and alignment
rules in CalculateStackSlotSize / CalculateStackSlotAlignment etc.
As a related change, the ABI routines have to be modified to support
passing floating-point types in GPRs. This is necessary because with
homogeneous aggregates of 4-byte float type we can now run out of FPRs
*before* we run out of the 64-byte argument save area that is shadowed
by GPRs. Any extra floating-point arguments that no longer fit in FPRs
must now be passed in GPRs until we run out of those too.
Note that there was already code to pass floating-point arguments in
GPRs used with vararg parameters, which was done by writing the argument
out to the argument save area first and then reloading into GPRs. The
patch re-implements this, however, in favor of code packing float arguments
directly via extension/truncation, BITCAST, and BUILD_PAIR operations.
This is required to support the ELFv2 ABI, since we cannot unconditionally
write to the argument save area (which the caller might not have allocated).
The change does, however, affect ELFv1 varags routines too; but even here
the overall effect should be advantageous: Instead of loading the argument
into the FPR, then storing the argument to the stack slot, and finally
reloading the argument from the stack slot into a GPR, the new code now
just loads the argument into the FPR, and subsequently loads the argument
into the GPR (via BITCAST). That BITCAST might imply a save/reload from
a stack temporary (in which case we're no worse than before); but it
might be implemented more efficiently in some cases.
The final part of the patch enables up to 8 FPRs and VRs for argument
return in PPCCallingConv.td; this is required to support returning
ELFv2 homogeneous aggregates. (Note that this doesn't affect other ABIs
since LLVM wil only look for which register to use if the parameter is
marked as "direct" return anyway.)
Reviewed by Hal Finkel.
llvm-svn: 213493
2014-07-21 08:13:26 +08:00
|
|
|
tail call void @test3([8 x float] %0, [5 x float] %1, double %d)
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @caller3
|
|
|
|
; CHECK: stfd 1, [[OFF:.*]](1)
|
|
|
|
; CHECK: ld 10, [[OFF]](1)
|
|
|
|
; CHECK: bl test3
|
|
|
|
|
|
|
|
declare void @test3([8 x float], [5 x float], double)
|
|
|
|
|
|
|
|
define float @callee4([8 x float] %a, [5 x float] %b, float %c) {
|
|
|
|
entry:
|
|
|
|
ret float %c
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @callee4
|
|
|
|
; CHECK: stw 10, [[OFF:.*]](1)
|
|
|
|
; CHECK: lfs 1, [[OFF]](1)
|
|
|
|
; CHECK: blr
|
|
|
|
|
|
|
|
define void @caller4(float %f) {
|
|
|
|
entry:
|
2015-03-14 02:20:45 +08:00
|
|
|
%0 = load [8 x float], [8 x float]* getelementptr inbounds (%struct.float8, %struct.float8* @g8, i64 0, i32 0), align 4
|
|
|
|
%1 = load [5 x float], [5 x float]* getelementptr inbounds (%struct.float5, %struct.float5* @g5, i64 0, i32 0), align 4
|
[PowerPC] ELFv2 aggregate passing support
This patch adds infrastructure support for passing array types
directly. These can be used by the front-end to pass aggregate
types (coerced to an appropriate array type). The details of the
array type being used inform the back-end about ABI-relevant
properties. Specifically, the array element type encodes:
- whether the parameter should be passed in FPRs, VRs, or just
GPRs/stack slots (for float / vector / integer element types,
respectively)
- what the alignment requirements of the parameter are when passed in
GPRs/stack slots (8 for float / 16 for vector / the element type
size for integer element types) -- this corresponds to the
"byval align" field
Using the infrastructure provided by this patch, a companion patch
to clang will enable two features:
- In the ELFv2 ABI, pass (and return) "homogeneous" floating-point
or vector aggregates in FPRs and VRs (this is similar to the ARM
homogeneous aggregate ABI)
- As an optimization for both ELFv1 and ELFv2 ABIs, pass aggregates
that fit fully in registers without using the "byval" mechanism
The patch uses the functionArgumentNeedsConsecutiveRegisters callback
to encode that special treatment is required for all directly-passed
array types. The isInConsecutiveRegs / isInConsecutiveRegsLast bits set
as a results are then used to implement the required size and alignment
rules in CalculateStackSlotSize / CalculateStackSlotAlignment etc.
As a related change, the ABI routines have to be modified to support
passing floating-point types in GPRs. This is necessary because with
homogeneous aggregates of 4-byte float type we can now run out of FPRs
*before* we run out of the 64-byte argument save area that is shadowed
by GPRs. Any extra floating-point arguments that no longer fit in FPRs
must now be passed in GPRs until we run out of those too.
Note that there was already code to pass floating-point arguments in
GPRs used with vararg parameters, which was done by writing the argument
out to the argument save area first and then reloading into GPRs. The
patch re-implements this, however, in favor of code packing float arguments
directly via extension/truncation, BITCAST, and BUILD_PAIR operations.
This is required to support the ELFv2 ABI, since we cannot unconditionally
write to the argument save area (which the caller might not have allocated).
The change does, however, affect ELFv1 varags routines too; but even here
the overall effect should be advantageous: Instead of loading the argument
into the FPR, then storing the argument to the stack slot, and finally
reloading the argument from the stack slot into a GPR, the new code now
just loads the argument into the FPR, and subsequently loads the argument
into the GPR (via BITCAST). That BITCAST might imply a save/reload from
a stack temporary (in which case we're no worse than before); but it
might be implemented more efficiently in some cases.
The final part of the patch enables up to 8 FPRs and VRs for argument
return in PPCCallingConv.td; this is required to support returning
ELFv2 homogeneous aggregates. (Note that this doesn't affect other ABIs
since LLVM wil only look for which register to use if the parameter is
marked as "direct" return anyway.)
Reviewed by Hal Finkel.
llvm-svn: 213493
2014-07-21 08:13:26 +08:00
|
|
|
tail call void @test4([8 x float] %0, [5 x float] %1, float %f)
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
; CHECK-LABEL: @caller4
|
|
|
|
; CHECK: stfs 1, [[OFF:.*]](1)
|
|
|
|
; CHECK: lwz 10, [[OFF]](1)
|
|
|
|
; CHECK: bl test4
|
|
|
|
|
|
|
|
declare void @test4([8 x float], [5 x float], float)
|
|
|
|
|