<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi Jakob,<div><br></div><div>Here is a patch proposal for the aggressive splitting problem we talked together.</div><div>If there is a simpler way to get the operand constraints from the live-range, I would be glad to update the patch accordingly.</div><div><br></div><div>** Context **</div><div><br></div><div>The greedy register allocator tries to split a live-range around each instruction where it is used or defined to relax the constraints on the entire live-range (this is a last chance split before falling back to spill).</div><div>The goal is to have a big live-range that is unconstrained (i.e., that can use the largest legal register class) and several small local live-range that carry the constraints implied by each instruction.</div><div>E.g.,</div><div>Let csti be the constraints on operation i.</div><div><br></div><div>V1=</div><div>op1 V1(cst1)</div><div>op2 V1(cst2)</div><div><br></div><div>V1 live-range is constrained on the intersection of cst1 and cst2.</div><div><br></div><div>tryInstructionSplit relaxes those constraints by aggressively splitting each def/use point:</div><div><div>V1=</div><div>V2 = V1</div><div>V3 = V2</div><div>op1 V3(cst1)</div><div>V4 = V2</div><div>op2 V4(cst2)</div></div><div><br></div><div>Because of how the coalescer infrastructure works, each new variable (V3, V4) that is alive at the same time as V1 (or its copy, here V2) interfere with V1. Thus, we end up with an uncoalescable copy for each split point.</div><div><br></div><div>The added test case demonstrates this problem.</div><div><br></div><div><br></div><div>** Proposed Solution **</div><div><br></div><div>Make tryInstructionSplit less aggressive.</div><div>To do that, we check if the split point actually relaxes the constraints on the whole live-range. If it does not, we do not insert it.</div><div>Indeed, it will not help the global allocation problem:</div><div>- V1 will have the same constraints.</div><div>- V1 will have the same interference + possibly the newly added split variable VS.</div><div>- VS will produce an uncoalesceable copy if alive at the same time as V1.</div><div><br></div><div>Note: During my measurements, I did not see any compile time or runtime regressions/improvement although several split points were not inserted. Measures were made on armv7s and x86_64 with LLVM test-sutie + external.</div><div><br></div><div>Thanks for your feedback.</div><div><br></div><div>Cheers,<br><div apple-content-edited="true">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">-Quentin</div>
</div>
</div></body></html>