[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
http://llvm.org/bugs/show_bug.cgi?id=22832
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
bug.ll
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
convention.
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