Hi All,
I found some cases where a spill of a live range in a block is reloaded only
in one of its successors, and there is no reload in other paths through
other successors. Since the spill is reloaded only in a certain path, it
must be okay to sink such spill close to its reloads. In the AArch64 code
below, there is a spill(x2) in the entry, but this value is reloaded only
in %bb.1, not in .LBB2_32. If we sink the spill (str x2, [sp, #120]) from
the entry to its successor (%bb.1), the load-from-store promotion might
catch this and replace the ldr in %bb.1 with a mov instruction. As we move
such spill down to its successor, we can also encourage more shrink-wrapping
as well.
.globl _mytest
// %bb.0: // %entry
sub sp, sp, #224 // =224
stp x28, x27, [sp, #128] // 8-byte Folded Spill
stp x26, x25, [sp, #144] // 8-byte Folded Spill
stp x24, x23, [sp, #160] // 8-byte Folded Spill
stp x22, x21, [sp, #176] // 8-byte Folded Spill
stp x20, x19, [sp, #192] // 8-byte Folded Spill
stp x29, x30, [sp, #208] // 8-byte Folded Spill
ldrsw x8, [x0, #4424]
sxtw x10, w2 <------------- w2 is the use of
spilled value before spill.
sxtw x12, w1
madd x8, x8, x10, x12
ldr x9, [x0, #8]
add x9, x9, x8, lsl #2
ldrh w11, [x9]
ldrh w10, [x0, #16]
str x2, [sp, #120] // 8-byte Folded Spill
<------------- spill !!!
cmp w11, w10
b.eq .LBB2_32
// %bb.1: // %if.end
ldr x13, [sp, #120] // 8-byte Folded Reload
<-------------- reload !!
< omitted >
:
.LBB2_32: // %cleanup <----- no
reload from [sp, #120]
ldp x29, x30, [sp, #208] // 8-byte Folded Reload
ldp x20, x19, [sp, #192] // 8-byte Folded Reload
ldp x22, x21, [sp, #176] // 8-byte Folded Reload
ldp x24, x23, [sp, #160] // 8-byte Folded Reload
ldp x26, x25, [sp, #144] // 8-byte Folded Reload
ldp x28, x27, [sp, #128] // 8-byte Folded Reload
add sp, sp, #224 // =224
ret
Unless there is hidden issues that prevent it from being sunk, I think such
sinking should be done after RA because sinking it down during RA will
extend the live range of the spilled value. Please let me know if there any
hidden issue that I miss here? I may happy to hear any opinion about it.
Thanks,
Jun
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180222/a9be5f13/attachment-0001.html>
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Jun Lim
via llvm-dev
Sent: Thursday, February 22, 2018 11:05 AM
Hi All,
I found some cases where a spill of a live range in a block is reloaded only
in one of its successors, and there is no reload in other paths through
other successors. Since the spill is reloaded only in a certain path, it
must be okay to sink such spill close to its reloads. In the AArch64 code
below, there is a spill(x2) in the entry, but this value is reloaded only
in %bb.1, not in .LBB2_32. If we sink the spill (str x2, [sp, #120]) from
the entry to its successor (%bb.1), the load-from-store promotion might
catch this and replace the ldr in %bb.1 with a mov instruction. As we move
such spill down to its successor, we can also encourage more shrink-wrapping
as well.
.globl _mytest
// %bb.0: // %entry
sub sp, sp, #224 // =224
stp x28, x27, [sp, #128] // 8-byte Folded Spill
stp x26, x25, [sp, #144] // 8-byte Folded Spill
stp x24, x23, [sp, #160] // 8-byte Folded Spill
stp x22, x21, [sp, #176] // 8-byte Folded Spill
stp x20, x19, [sp, #192] // 8-byte Folded Spill
stp x29, x30, [sp, #208] // 8-byte Folded Spill
ldrsw x8, [x0, #4424]
sxtw x10, w2 <------------- w2 is the use of
spilled value before spill.
sxtw x12, w1
madd x8, x8, x10, x12
ldr x9, [x0, #8]
add x9, x9, x8, lsl #2
ldrh w11, [x9]
ldrh w10, [x0, #16]
str x2, [sp, #120] // 8-byte Folded Spill
<------------- spill !!!
cmp w11, w10
b.eq .LBB2_32
// %bb.1: // %if.end
Presumably there is a redefinition of x2 somewhere in here, otherwise it
wouldn't need to be spilled at all?
ldr x13, [sp, #120] // 8-byte Folded Reload
<-------------- reload !!
< omitted >
:
.LBB2_32: // %cleanup <----- no
reload from [sp, #120]
ldp x29, x30, [sp, #208] // 8-byte Folded Reload
ldp x20, x19, [sp, #192] // 8-byte Folded Reload
ldp x22, x21, [sp, #176] // 8-byte Folded Reload
ldp x24, x23, [sp, #160] // 8-byte Folded Reload
ldp x26, x25, [sp, #144] // 8-byte Folded Reload
ldp x28, x27, [sp, #128] // 8-byte Folded Reload
add sp, sp, #224 // =224
ret
Unless there is hidden issues that prevent it from being sunk, I think such
sinking should be done after RA because sinking it down during RA will
extend the live range of the spilled value. Please let me know if there any
hidden issue that I miss here? I may happy to hear any opinion about it.
Thanks,
Jun
--
Geoff Berry
Employee of Qualcomm Datacenter Technologies, Inc.
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180222/df184a34/attachment.html>
On 2018-02-22 11:14, gberry at codeaurora.org wrote:> FROM: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] ON BEHALF OF > Jun Lim via llvm-dev > SENT: Thursday, February 22, 2018 11:05 AM > > Hi All, > > I found some cases where a spill of a live range in a block is > reloaded only in one of its successors, and there is no reload in > other paths through other successors. Since the spill is reloaded only > in a certain path, it must be okay to sink such spill close to its > reloads. In the AArch64 code below, there is a spill(x2) in the entry, > but this value is reloaded only in %bb.1, not in .LBB2_32. If we sink > the spill (str x2, [sp, #120]) from the entry to its successor > (%bb.1), the load-from-store promotion might catch this and replace > the ldr in %bb.1 with a mov instruction. As we move such spill down to > its successor, we can also encourage more shrink-wrapping as well. > > .globl _mytest > > // %bb.0: // %entry > > sub sp, sp, #224 // =224 > > stp x28, x27, [sp, #128] // 8-byte Folded Spill > > stp x26, x25, [sp, #144] // 8-byte Folded Spill > > stp x24, x23, [sp, #160] // 8-byte Folded Spill > > stp x22, x21, [sp, #176] // 8-byte Folded Spill > > stp x20, x19, [sp, #192] // 8-byte Folded Spill > > stp x29, x30, [sp, #208] // 8-byte Folded Spill > > ldrsw x8, [x0, #4424] > > sxtw x10, w2 <------------- w2 is the > use of spilled value before spill. > > sxtw x12, w1 > > madd x8, x8, x10, x12 > > ldr x9, [x0, #8] > > add x9, x9, x8, lsl #2 > > ldrh w11, [x9] > > ldrh w10, [x0, #16] > > str x2, [sp, #120] // 8-byte Folded Spill > <------------- spill !!! > > cmp w11, w10 > > b.eq .LBB2_32 > > // %bb.1: // %if.end > > Presumably there is a redefinition of x2 somewhere in here, otherwise > it wouldn't need to be spilled at all? >In the test case I’m looking at, x2 is redefined in later blocks, but no redefinition of x2 before reloading in %bb.1.> ldr x13, [sp, #120] // 8-byte Folded Reload > <-------------- reload !! > > < omitted > > > : > > .LBB2_32: // %cleanup > <----- no reload from [sp, #120] > > ldp x29, x30, [sp, #208] // 8-byte Folded Reload > > ldp x20, x19, [sp, #192] // 8-byte Folded Reload > > ldp x22, x21, [sp, #176] // 8-byte Folded Reload > > ldp x24, x23, [sp, #160] // 8-byte Folded Reload > > ldp x26, x25, [sp, #144] // 8-byte Folded Reload > > ldp x28, x27, [sp, #128] // 8-byte Folded Reload > > add sp, sp, #224 // =224 > > ret > > Unless there is hidden issues that prevent it from being sunk, I think > such sinking should be done after RA because sinking it down during RA > will extend the live range of the spilled value. Please let me know if > there any hidden issue that I miss here? I may happy to hear any > opinion about it. > > Thanks, > > Jun > > -- > > Geoff Berry > > Employee of Qualcomm Datacenter Technologies, Inc. > > Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm > Technologies, Inc. Qualcomm Technologies, Inc. is a member of the > Code Aurora Forum, a Linux Foundation Collaborative Project.-- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.