<div dir="ltr">Hi Nick,<div><br></div><div>I'm not an expert on inlining algorithms so please excuse my naivite. But usually these "top-down versus bottom-up" arguments (in other domains, at least), come to the obvious conclusion that both have merits so let's create a hybrid. Why is this not the case here too?</div>
<div><br></div><div>As far as I can tell, Yin's pass simply provides a method to add global context to local decisions. Algorithms such as a bottom-up inliner analyze a callsite and assign it a value. This could be bottom-up or top-down, it doesn't really matter. What matters is that eventually, all (rational) callsites end up in the same sorted datastructure and are addressed in order.</div>
<div><br></div><div>Am I missing something?</div><div><br></div><div>Cheers,</div><div><br></div><div>James</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 6 August 2014 08:54, Nick Lewycky <span dir="ltr"><<a href="mailto:nicholas@mxc.ca" target="_blank">nicholas@mxc.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">Hal Finkel wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd like you to elaborate on your assertion here, however, that a "topdown inliner is going to work best when you have the whole program." It seems to me that, whole program or not, a top-down inlining approach is exactly what you want to avoid the vector-push_back-cold-path-<u></u>inlining problem (because, from the caller, you see many calls to push_back, which is small -- because the hot path is small and the cold path has not (yet) been inlined -- and inlines them all, at which point it can make a sensible decision about the cold-path calls).<br>

</blockquote>
<br></div>
I don't see that. You get the same information when looking at a pair of functions and deciding whether to inline. With the bottom-up walk, we analyze the caller and callee in their entirety before deciding whether to inline. I assume a top-down inliner would do the same.<br>

<br>
If you have a top-down traversal and you don't have the whole program, the first problem you have is a whole ton of starting points. At first blush bottom up seems to have the same problem, except that they are generally very straight-forward leaf functions -- setters and getters or little loops to test for a property. Top down you don't yet know what you've got, and it has lots of calls that may access arbitrary memory. In either case, you apply your metric to inline or not. Then you run the function-level passes to perform simplification. Bottom up, you're much more likely to get meaningful simplifications -- your getter/setter melts away. Top down you may remove some redundant loads or dead stores, but you still don't know what's going on because you have these opaque not-yet-analyzed callees in the way. If you couldn't analyze the memory before, inlining one level away hasn't helped you, and the function size has grown. You don't get the simplifications until you go all the way down the call stack to the setters and getters etc.<br>

<br>
There's a fix for this, and that's to perform a sort of symbolic execution and just keep track of what the program has done so far (ie. what values registers have taken on so far, which pointers have escaped etc.), and make each inlining decision in program execution order. But that fix doesn't get you very far if you haven't got a significant chunk of program to work with.<div class="HOEnZb">
<div class="h5"><br>
<br>
Nick<br>
______________________________<u></u>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>