The register allocator currently favors allocating a CSR over splitting/spilling a region. This in effect results in introducing more opportunity to save/restore CSR registers at prologue/epilogue. It hurts performance especially when there is no need of prologue/epilogue for the hot path. If we can save/restore non-CSR across call, then we don't use CSR during the function and we don't need to save/restore them at prologue/epilogue.
It also influences the shrink-wrapping directly if we must use CSR during the function. For now copies of parameter registers into CSR's in the entry block when the parameter is live across any calls in the function. And of course, this disables shrink-wrapping because the save point then must be the entry block. After the patch, live ranges allocated to CSR registers will be shortened and will only be used in cold places, so that we may get better chances to do shrink-wrapping.
I refine the adjusting CSR cost to enhance the RegAllocGreedy to favour splitting/spill the virtual register which is being allocated instead of allocate CSR directly. If use CSR, we need add load/store pair in prologue/epilogue. So if the cost caused by spillings which is introduced by trying to avoid using CSR is larger than load/store pair in prologue/epilogue, we would choose to use CSR. I make the raw cost to be 1 because the cost is load/store pair in prologue/epilogue if use CSR. so the cost is 1 time spill like the cost calculated in SpillPlacer. Then we need scale the cost relative to entry frequency.
It can directly help to expand the opportunity exposed to shrink-wrapping at later phase because it causes the use of CSR is delayed to the BB with the call instead of entry BB.It's trying to avoid the magic cost number for different target. The CSRCost is a relative times corresponding to the spill operation in prologue/epilogue.