The issue ----------
For a calling convention with a large set of CSRs, if shrink wrapping can't move the whole prologue/epilogue to the cold path, we can explicitly handle a subset of the CSRs via copies and register allocator will try to spill and reload this subset on the cold path. Without the proposed patches, all CSRs will be saved and restored in the prologue/epilogue.
Specifically, this is motivated by CXX_FAST_TLS calling convention on AArch64. Since the C++-style access function calls tlv_get_addr on Darwin, LR will be clobbered by tlv_get_addr and shrink wrapping will not be able to move the prologue/epilogue.
The patches -----------
There are two patches proposed for this issue. The target independent portion is in this review. The AArch64-specific portion will be in a separate review.
What is included in this patch -----------
The access function has a short entry and a short exit, the initialization block is only run the first time.
To improve the performance, we want to have a short frame at the entry and exit.
We explicitly handle most of the CSRs via copies. Only the CSRs that are not handled via copies will be in CSR_SaveList.
Frame lowering and prologue/epilogue insertion will generate a short frame in the entry and exit according to CSR_SaveList. The majority of the CSRs will
be handled by register allcoator. Register allocator will try to spill and reload them in the initialization block.
We add CSRsViaCopy, it will be explicitly handled during lowering.
1> we first set FunctionLoweringInfo->SplitCSR if conditions are met (a single exit block with a return; target supports SplitCSR; the calling convention is CXX_TLS), we also call TLI->handleSplitCSR(Entry, nullptr) to perform initialization. 2> we insert copies from CSRsViaCopy to virtual registers at beginning of the entry block and copies from virtual registers to CSRsViaCopy at beginning of the exit block. (this is implemented by handleSplitCSR(Entry, Exit)) 3> we also need to make sure the explicit copies will not be eliminated. (this is target-specific)
Thanks to Quentin for suggesting this!