[llvm-dev] Sink redundant spill after RA

[via llvm-dev]

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>