<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 14, 2020 at 2:22 PM Vedant Kumar <<a href="mailto:vedant_kumar@apple.com">vedant_kumar@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Snehasish,<br>
<br>
Thanks for sharing this great write-up.<br>
<br>
In past experiments, I found that splitting at the IR level (vs. at the codegen level) has a few drawbacks. You've discussed these, but just to recap:<br>
<br>
- IR-level splitting is necessarily more conservative. This is to avoid inadvertently increasing code size in the original function due to the cost of materializing inputs/outputs to the cold callee (you refer to this as 'residue'). (As Aditya pointed out, some of the work re: splitting penalty hasn't been upstreamed yet -- I'll try to dust this off.)<br>
- It cannot split out @eh.typeid.for intrinsics, a common feature in exception handling code (<a href="http://llvm.org/PR39545" rel="noreferrer" target="_blank">llvm.org/PR39545</a>).<br>
- It must be run very late in the pipeline. Splitting either before inlining, or shortly after, appears to regress performance across spec variants (with/without pgo, see <span class="gmail_default" style="font-size:small"></span>D58258).<br>
<br>
It's exciting to see this work, as it can side-step the first two issues. I'm not sure whether this is on your radar, but we do see some benefit from having the machine outliner run after IR-level splitting. I have not done a study of how this compares with partial inlining + late splitting, that could be interesting future work.<br></blockquote><div><span class="gmail_default" style="font-size:small">That's an interesting idea. Can you share more details about the benefit - is this a performance improvement you observe or better code size? Also what benchmarks was this observed on?</span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I haven't kept up to date on the work done to support basic block sections in debug info. I'll note that it was a challenge to fix up debug info after IR-level splitting (ultimately this was handled in <span class="gmail_default" style="font-size:small"></span>D72795). I'm not sure whether any of that is transferable, but feel free to cc me on reviews if you think it is.<br></blockquote><div><div class="gmail_default" style="font-size:small">We do have support for debug info in basic block sections (added in <a href="https://reviews.llvm.org/D78851">https://reviews.llvm.org/D78851</a>). As we test more applications we are fixing up issues (eg. <a href="https://reviews.llvm.org/D85085">https://reviews.llvm.org/D85085</a>). Thanks for the offer and we will ping you if appropriate.</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
vedant</blockquote></div></div>