<div dir="ltr"><div><div><div><div>One thing I thought about doing a while back and never really wrote a POC for is the following:<br></div>- Make FirstCSRCost a property of the MachineBasicBlock (or create a map of MBB* -> FirstCSRCost)<br></div><div>- Implement a pre-RA pass that will populate the map as follows:<br></div><div>  - Identify all blocks with calls<br></div><div>  - Find the nearest common dominator (NCD) to all those blocks (not strict so that a block with a call might be that NCD)<br></div><div>  - If the NCD is the entry block, CSR allocation is cheap in all blocks<br></div><div>  - Make CSR allocation cheap in blocks that are in the dominator tree rooted at NCD<br></div><div><br></div><div>The idea would be to favour CSR allocation in blocks that might be eligible for the prologue and favour splitting in blocks that we'd prefer not to have a prologue in (or before).<br></div><div>Then a CFG such as this:<br><span style="font-family:monospace,monospace">    A<br>   / \<br>  B   C<br>  |  / \<br>  | D   E<br>  | |  /<br>  | | /<br>  | |/<br>  | /<br>  |/<br>  F</span><br></div><div><br>- Assume calls are in B and <b>any_of</b>(C,D,E): CSR allocation is cheap everywhere<br></div><div>- Assume calls are in C or <b>all_of</b>(D,E): CSR allocation is cheap in <b>all_of</b>(C,D,E); CSR allocation is expensive in <b>all_of</b>(A,B,F)<br></div><div>- Assume only call is in <b>any_of</b>(B,D,E): CSR allocation is cheap only in that block, expensive everywhere else<br></div><div><br><br></div><div>I think this construction would give us what we want, but there may be [obvious] counter-examples I haven't thought of.<br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 31, 2017 at 8:38 PM, via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 2017-10-30 21:20, Hal Finkel wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/30/2017 12:20 PM, <a href="mailto:junbuml@codeaurora.org" target="_blank">junbuml@codeaurora.org</a> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2017-10-27 19:50, Hal Finkel wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/27/2017 03:32 PM, Jun Lim via llvm-dev wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When compiling C code below for AArach64, I saw that shrink-wrapping<br>
didn't happen due to the very early uses of CSRs in the entry block.<br>
So CSR spills/reloads are executed even when the early exit block is<br>
taken.<br>
<br>
int getI(int i);<br>
<br>
int foo(int *P, int i) {<br>
<br>
if (i>0)<br>
<br>
return P[i];<br>
<br>
i = getI(i);<br>
<br>
return P[i];<br>
<br>
}<br>
<br>
It's not that hard to find such cases where RegAllocGreedy<br>
aggressively allocates a CSRs when a live range expands across a<br>
call-site.  That's because of the conservatively initialized<br>
CSRCost, causing RegAllocGreedy to strongly favour allocating a CSR<br>
over splitting a region. Since allocation of CSRs requires the cost<br>
of spilling CSRs, allocating CSRs is not always beneficial. Like the<br>
case above, if a function has an early exit code, we may want to be<br>
less aggressive on the first allocation of CSR in the entry block by<br>
increasing the CSRCost.<br>
<br>
Previously, I proposed <a href="https://reviews.llvm.org/D34608" rel="noreferrer" target="_blank">https://reviews.llvm.org/D3460<wbr>8</a> in this<br>
matter, but the way I detect the profitable cases and the way I<br>
increase the CRSCost was somewhat unclear. Now, I'm thinking to less<br>
aggressive on the first allocation of CSR in the entry block in case<br>
where the function has an early exit so that encourage more<br>
shrink-wrapping and avoid executing CSR spill/recover when the early<br>
exit is taken. By sending this out, I just want to get any high<br>
level feedback early. Please let me know if anyone has any opinion<br>
about this.<br>
</blockquote>
<br>
So the heuristic will have nothing to do with the presence of calls?<br>
Might this increase spilling in loops?<br>
<br>
 -Hal<br>
<br>
</blockquote>
<br>
Before allowing the first allocation from CSRs, I will check if the virtual register is really live across a call in other blocks. If the function have a call in entry or exit, we don't need to increase the CSRCost. This heuristic will be applied only for the very first allocation from CSRs only in the entry block when the function has an early exit; if a CSR is already allocated in the function, we will use the current default global CSRCost.<br>
<br>
Even after increasing the CSRCost, we should end up allocating the first CSR if the cost of splitting the live-range is still higher than the increased CSRCost. I believe the amount we want to increase the CSRCost must be target-dependent, but it must be conservative enough to avoid too many copies in the related spots.<br>
</blockquote>
<br>
Thanks for explaining.<br>
<br>
I suppose you'll want to make sure that the call(s) in question come<br>
after the early exit (i.e., that there aren't calls before the early<br>
exit)?<br>
<br>
</blockquote>
<br></div></div>
I will check if a virtual register is live across only calls which will be executed when the early exit is not taken. By increasing CSRcost for such case, we increase chances to avoid executing CSR spill/recover when the early exit is taken.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When you say "only in the entry block" you mean that the live range<br>
starts in the entry block, right (i.e., that it is a function<br>
parameter or a vreg defined by some instruction in the entry block)?<br>
</blockquote>
<br></span>
Yes.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Does it matter that it is in the entry block, or do you only need it<br>
to come before the early exit and have an execution frequency <= to<br>
the entry block's execution frequency?<br>
</blockquote>
<br></span>
The reason I specifically check the entry block is because for now I see the early exit happen only in entry block; limiting that the early exit condition is checked in the entry block and branch to the exit block directly from the entry block if hitting the condition. If overall approach is reasonable, we can certainly extend it.<span class="im HOEnZb"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 -Hal<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Jun<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote>
<br>
-- Hal Finkel<br>
Lead, Compiler Technology and Programming Languages<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</blockquote>
<br>
</blockquote></blockquote>
<br>
-- <br></span><span class="im HOEnZb">
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.<br>
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.<br></span><div class="HOEnZb"><div class="h5">
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>