[llvm-dev] Sink redundant spill after RA

[via llvm-dev]

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.