<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 12, 2020 at 11:56 AM Snehasish Kumar via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</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"><div dir="ltr"><div dir="ltr"><div style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 12, 2020 at 10:24 AM aditya kumar <<a href="mailto:hiraditya@gmail.com" target="_blank">hiraditya@gmail.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"><div dir="ltr"><div dir="ltr"><div>> Just chiming in about the outliner stuff. (In general, I think it's desirable to have multiple options for how early/late a pass runs.)</div><div><br></div><div>I'm wondering if MachineOutliner can be augmented to add MachineFunctionSplitter functionalities as well. If the analysis part of MachineOutliner can allow single basic block outlining with some cost models. </div></div></div></blockquote><div><br></div><div style="font-size:small">The MachineOutliner and MachineFunctionSplitter target orthogonal use cases. Namely, the MachineOutliner optimizes for binary size while the MachineFunctionSplitter optimizes for performance. Attempting to reconcile the differences to fully address the opportunity along both dimensions doesn't seem like a fruitful goal. Furthermore, the key to better performance is not only the timing of the MachineFunctionSplitter pass but also the extraction methodology, i.e. using basic block sections. Basic blocks sections is a nascent feature and needs more widespread use and rigorous testing before being incorporated with a mature, more widely used pass. Today, we only use basic block sections for x86 ELF targets.</div></div></div></blockquote><div><br></div><div>I agree with this.  The only thing common between MachineOutliner (MO) and MachineFunctionSplitter(MFS) is that they move code out of the function.  Otherwise, they do very different things.  MO uses powerful analyses to determine basic blocks that could be shared across multiple functions to outline. MFS just moves cold basic blocks out of the function.  MO could be tweaked independently for performance , like not outlining a hot basic block for locality reasons.</div><div> </div><div>Even the mechanism to move basic blocks out of the function is very different for MFS and MO.  MO uses call-ret semantics where MFS uses basic block sections which just uses jump instructions.  Please see below for why it is going to be hard for MO to use basic block sections.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div style="font-size:small"><br></div><div style="font-size:small">There is an interesting follow on though -- can we use basicblock sections as the extraction methodology in MachineOutliner, thus lowering the overhead of outlining? This is something we can revisit once basic block sections is more mature.</div></div></div></blockquote><div><br></div><div>It is going to take some work to have MO use basic block sections and is not straightforward.  MFS can use basic block sections trivially because the split basic block still belongs to only one function.  However, with MO, when a basic block is shared, the call-return semantic is the easier choice when outlining, as it needs to know where to return to.  Basic block sections do not have that power and we need to inject code to remember where to return to, mimic call semantics.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><br></div><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Aditya Kumar<div>Compiler Engineer</div><div><a href="https://bitsimplify.com" target="_blank">https://bitsimplify.com</a><br></div></div></div></div></div></div></div></div></div><br></div>
</blockquote></div></div>
_______________________________________________<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="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>