[LLVMbugs] [Bug 22832] New: Teach greedy register allocator about "free" patchpoint uses

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Fri Mar 6 18:49:08 PST 2015


            Bug ID: 22832
           Summary: Teach greedy register allocator about "free"
                    patchpoint uses
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: atrick at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 14002
  --> http://llvm.org/bugs/attachment.cgi?id=14002&action=edit

There are several places where the spiller used by the register allocator
should be fixed to reason about virtual register uses that can be spilled for
free. Patchpoint operands that are in the set of "live values" (as opposed to
call arguments) should be able to be folded by the target (see
foldMemoryOperand). Generally, we consider runtime to be on the slow path, so
we don't care if these values are in registers or stack locations. If we did
care then the frontend should use call arguments instead with anyregcc

This test case exposes a specific issue in RAGreedy::tryLocalSplit.
$ llc bug.ll -debug-only=regalloc

The test case pseudo-IR is:

0: %v1 = call()
1: inlineasm "clobber-all"
2: patchpoint %v1
3: patchpoint %v1

Because this is all in one basic block, RAGreedy tries to find an optimial
local live range that can be assigned a physical register and spans as many
uses as possible. It treats all uses as 

Fixing this is probably not hard but not trivial either because just
eliminating patchpoint uses from the SpillKit's use set seems misleading and
dangerous. Ideally the heuristics would be adjusted for these free uses
instead. This is just involved enough that I won't have time to fix it myself.

My suggestion for anyone hitting this with a JIT is to try basic regalloc
instead. It should avoid this problem and give you better compile time.
(see createTargetRegisterAllocator).

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/20150307/5c45f109/attachment.html>

More information about the llvm-bugs mailing list