Page MenuHomePhabricator

New statepoint spilling mechanism
Needs RevisionPublic

Authored by linzj on Sep 5 2019, 11:38 PM.

Details

Summary

Remove the original statepoint's spill mechanism. New mechanism relies on LLVM's greedy register allocator. The original one has it own spill management, which cause conflict in some situation. There would be a chaotic code which contain lots of memory reads/writes, and much larger stack size.

Event Timeline

linzj created this revision.Sep 5 2019, 11:38 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 5 2019, 11:38 PM
linzj updated this revision to Diff 219033.Sep 5 2019, 11:44 PM

Remove logs.

linzj updated this revision to Diff 219034.Sep 5 2019, 11:47 PM

Remove an unused function.

linzj updated this revision to Diff 219035.Sep 5 2019, 11:48 PM

Remove an unused include file.

Harbormaster completed remote builds in B37828: Diff 219035.
qcolombet requested changes to this revision.Sep 6 2019, 11:19 AM

Hi,

I don't think this patch is correct in the sense that having statepoints depend on GreedyRegAlloc is a non-starter.
Indeed, that means that now any configuration that doesn't use greedy reg alloc (like fast or basic reg alloc) will generate incorrect code with respect to state point spilling.

What problem do you see with the current handling of statepoints?

Cheers,
-Quentin

llvm/include/llvm/CodeGen/SlotIndexes.h
334

Having 0-sized SmallVector looks weird.
Just use std::vector if you don't need the inline storage.

This revision now requires changes to proceed.Sep 6 2019, 11:19 AM
linzj added a comment.Sep 6 2019, 8:31 PM

Hi,

I don't think this patch is correct in the sense that having statepoints depend on GreedyRegAlloc is a non-starter.
Indeed, that means that now any configuration that doesn't use greedy reg alloc (like fast or basic reg alloc) will generate incorrect code with respect to state point spilling.

What problem do you see with the current handling of statepoints?

Cheers,
-Quentin

Thanks for the review. The problem canbe seen when you llc the testcase I uploaded. With my patch, the function only saves 56 bytes for variables. Without, it will save much more. And that's only a simple case. In the situation I met before, some function reloads for the statepoint's spill, Then spill for statepoint's reload. They are not compatible, some one of them should leave.