Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Teach greedy register allocator about "free" patchpoint uses #23206

Open
atrick opened this issue Mar 7, 2015 · 1 comment
Open

Teach greedy register allocator about "free" patchpoint uses #23206

atrick opened this issue Mar 7, 2015 · 1 comment
Labels
bugzilla Issues migrated from bugzilla llvm:regalloc

Comments

@atrick
Copy link
Contributor

atrick commented Mar 7, 2015

Bugzilla Link 22832
Version trunk
OS All
Attachments bug.ll
CC @hfinkel,@qcolombet

Extended Description

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).

@atrick
Copy link
Contributor Author

atrick commented Mar 7, 2015

... my description was truncated.

RAGreedy::tryLocalSplit treats all uses the same. It then tries to find single range that covers the most users. In the above example, it finds the range [2,3]. It thens inserts a single reload before slot #​2 and reuses %rbx. for %v1.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla llvm:regalloc
Projects
None yet
Development

No branches or pull requests

2 participants