<story><title>LLVM merges machine function splitter for reduction in TLB misses</title><url>https://lists.llvm.org/pipermail/llvm-dev/2020-August/144012.html</url></story><parent_chain></parent_chain><comment><author>account42</author><text>In their comparisons they explain that the existing Hot Cold Split creates new functions for the cold parts which brings overheads due to calling conventions and exception handling. Their new method avoids that by using simple jumps.&lt;p&gt;I wish compilers were able to optimize functions boundaries for visible but not inlined better so they could optimize those function call overheads away automatically. There is no reason for a compiler to limit itself to the system ABI for completely internal functions.&lt;p&gt;Besides leaving values in the registers they are already in instead of moving them to where the ABI says they should be, this could enable passing C++ objects such as std::unique_ptr in registers where the current ABI forbids this. Or to eliminate nop destructors for objects that are always moved from in the called functions.&lt;p&gt;In general, I think compilers should see function boundaries in the source code as a mere hint when it comes to code generation just like they already do with the register keyword.&lt;p&gt;Is there any existing compiler work to optimize function calls where the implementation and all uses are visible in the translation unit?</text></comment>
<story><title>LLVM merges machine function splitter for reduction in TLB misses</title><url>https://lists.llvm.org/pipermail/llvm-dev/2020-August/144012.html</url></story><parent_chain></parent_chain><comment><author>MaxBarraclough</author><text>&amp;gt; Google engineers found a 2.33% runtime improvement with a ~32% reduction in iTLB and sTLB misses&lt;p&gt;Not bad. Presumably this will benefit every compiler that uses LLVM, not just Clang.</text></comment>