Files
website-build/compiler-inlining.typ.nano.html
2025-08-29 15:47:42 +02:00

1 line
6.4 KiB
HTML
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!doctype html><title>Automatically inlining functions is not easy</title><meta charset=utf-8><body><div><p><br><h1>Automatically inlining functions is not easy</h1><p><span style=font-size:9pt><p>Last modified: 11. August 2025 16:38 (Git #<code><code style=white-space:pre-wrap>9c2913af</code></code>)<p>Written by <a href=https://alex.vxcc.dev>alex_s168</a></span></div><div><p><br><h2>Introduction</h2><p>Function calls have some overhead, which can sometimes be a big issue for other optimizations. Because of that, compiler backends (should) inline function calls. There are however many issues with just greedily inlining calls…</div><div><p><br><h2>Greedy inlining with heuristics</h2><p>This is the most obvious approach. We can just inline all functions with only one call, and then inline calls where the inlined function does not have many instructions.<p>Example:<p><code><pre><code>function f32 $square(f32 %x) {<br>@entry:<br> // this is stupid, but I couldn't come up with a better example<br> f32 %e = add %x, 0<br> f32 %out = add %e, %x<br> ret %out<br>}<br><br>function f32 $hypot(f32 %a, f32 %b) {<br>@entry:<br> f32 %as = call $square(%a)<br> f32 %bs = call $square(%b)<br> f32 %sum = add %as, %bs<br> f32 %o = sqrt %sum<br> ret %o<br>}<br><br>function f32 $tri_hypot({f32, f32} %x) {<br> f32 %a = extract %x, 0<br> f32 %b = extract %x, 1<br> f32 %o = call $hypot(%a, %b) // this is a "tail call"<br> ret %o<br>}<br><br>// let's assume that $hypot is used someplace else in the code too</code></pre></code></div><div><br>Lets assume our inlining treshold is 5 operations. Then we would get Waait there are multiple options…</div><div><p><br><h3>Issue 1: (sometimes) multiple options</h3><p>If we inline the <code><code style=white-space:pre-wrap>$square</code></code> calls, then <code><code style=white-space:pre-wrap>$hypot</code></code> will have too many instructions to be inlined into <code><code style=white-space:pre-wrap>$tri_hypot</code></code>:<p><code><pre><code>...<br>function f32 $hypot(f32 %a, f32 %b) {<br>@entry:<br> // more instructions than our inlining treshold:<br> f32 %ase = add %a, 0<br> f32 %as = add %ase, %a<br> f32 %bse = add %b, 0<br> f32 %bs = add %bse, %b<br> f32 %sum = add %as, %bs<br> f32 %o = sqrt %sum<br> ret %o<br>}<br>...</code></pre></code></div><div><p><br>The second option is to inline the <code><code style=white-space:pre-wrap>$hypot</code></code> call into <code><code style=white-space:pre-wrap>$tri_hypot</code></code>. (There are also some other options)<p>Now in this case, it seems obvious to prefer inlining <code><code style=white-space:pre-wrap>$square</code></code> into <code><code style=white-space:pre-wrap>$hypot</code></code>.</div><div><p><br><h3>Issue 2: ABI requirements on argument passing</h3><p>If we assume the target ABI only has one f32 register for passing arguments, then we would have to generate additional instructions for passing the second argument of <code><code style=white-space:pre-wrap>$hypot</code></code>, and then it might actually be more efficient to inline <code><code style=white-space:pre-wrap>$hypot</code></code> instead of <code><code style=white-space:pre-wrap>$square</code></code>.<p>This example is not realistic, but this issue actually occurs when compiling lots of code.<p>Another related issue is that having more arguments arranged in a fixed way will require lots of moving data arround at the call site.<p>A solution to this is to make the heuristics not just output code size, but also make it depend on the number of arguments / outputs passed to the function.</div><div><p><br><h3>Issue 3: (sometimes) prevents optimizations</h3><p><code><pre><code>function f32 $myfunc(f32 %a, f32 %b) {<br>@entry:<br> f32 %sum = add %a, %b<br> f32 %sq = sqrt %sum<br> ...<br>}<br><br>function $callsite(f32 %a, f32 %b) {<br>@entry:<br> f32 %as = add %a, %a<br> f32 %bs = add %b, %b<br> f32 %x = call $myfunc(%as, %bs)<br> ...<br>}</code></pre></code><p>If the target has a efficient <code><code style=white-space:pre-wrap>hypot</code></code> operation, then that operation will only be used if we inline <code><code style=white-space:pre-wrap>$myfunc</code></code> into <code><code style=white-space:pre-wrap>$callsite</code></code>.<p>This means that inlining is now depended on… instruction selection??<p>This is not the only optimization prevented by not inlining the call. If <code><code style=white-space:pre-wrap>$callsite</code></code> were to be called in a loop, then not inlining would prevent vectorization.</div><div><p><br><h2>Function outlining</h2><p>A related optimization is “outlining”. Its the opposite to inlining. It moves duplicate code into a function, to reduce code size, and sometimes increase performance (because of instruction caching)<p>If we do inlining seperately from outlining, we often get unoptimal code.</div><div><p><br><h2>A better approach</h2><p>We can instead first inline <strong>all</strong> inlinable calls, and <strong>then</strong> perform more agressive outlining.</div><div><p><br><h3>Step 1: inlining</h3><p>We inline <strong>all</strong> function calls, except for:<ul><li>self recursion (obviously)<li>functions explicitly marked as no-inline by the user</ul></div><div><p><br><h3>Step 2: detect duplicate code</h3><p>There are many algorithms for doing this.<p>The goal of this step is to both:<ul><li>maximize size of outlinable section<li>minimize size of code</ul></div><div><p><br><h3>Step 3: slightly reduce size of outlinable section</h3><p>The goal is to reduce size of outlinable sections, to make the code more optimal.<p>This should be ABI and instruction depended, and have the goal of:<ul><li>reducing argument shuffles required at all call sites<li>reducing register preassure<li>not preventing good isel choices and optimizations.</ul><p>this is also dependent on the targetted code size.</div><div><p><br><h3>Step 4: perform outlining</h3><p>This is obvious.</div><div><p><br><h3>Issue 1: high compile-time memory usage</h3><p>Inlining <strong>all</strong> function calls first will increase the memory usage during compilation by A LOT<p>Im sure that there is a smarter way to implement this method, without actually performing the inlining…</div><div><p><br><h2>Conclusion</h2><p>Function inlining is much more complex than one might think.<p>PS: No idea how to implement this…<p>Subscribe to the <a href=atom.xml>Atom feed</a> to get notified about futre compiler-related articles.</div>