[llvm-bugs] [Bug 25210] New: The computation of spill weights and the actual insertion of the spill code may not match

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Oct 16 10:27:41 PDT 2015


https://llvm.org/bugs/show_bug.cgi?id=25210

            Bug ID: 25210
           Summary: The computation of spill weights and the actual
                    insertion of the spill code may not match
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Register Allocator
          Assignee: unassignedbugs at nondot.org
          Reporter: qcolombet at apple.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Right now, the spill weights used in the register allocator are computed by
lvm::calculateSpillWeightsAndHints and the VirtRegAuxInfo class.
On the other end, the code inserting the spill code is done by a spiller
instance, for instance the InlineSpiller for the GreedyAllocator.

The problem here is that the computation can be completed off compared to what
the spiller actually does. The weight is an over approximation of the actual
spill cost and because of that it is possible to spill variables that are
actually more expensive than other, in particular when rematerialization is
involved.

It would be better to unify those information. The spiller should be able to
give those weights instead of relying on a different implementation.

For instance, we patched the weight computation to better match the
InlinerSpiller behavior in:
r244439 | rlougher | 2015-08-10 04:59:44 -0700 (Mon, 10 Aug 2015) | 13 lines

Trace copies when checking for rematerializability in spill weight calculation

PR24139 contains an analysis of poor register allocation. One of the findings
was that when calculating the spill weight, a rematerializable interval once
split is no longer rematerializable. This is because the isRematerializable
check in CalcSpillWeights.cpp does not follow the copies introduced by live
range splitting (after splitting, the live interval register definition is a
copy which is not rematerializable).

We shouldn’t have to do that!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20151016/726b340d/attachment.html>


More information about the llvm-bugs mailing list