<div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 28, 2012 at 10:39 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank" class="cremed">dberlin@dberlin.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Aug 29, 2012 at 12:11 AM, Ramanarayanan, Ramshankar<br>
<<a href="mailto:Ramshankar.Ramanarayanan@amd.com" class="cremed">Ramshankar.Ramanarayanan@amd.com</a>> wrote:<br>
> I am wondering how O4 vs O3 do inlining. With O4 it looks like inlining is<br>
> done first on each file and then at linking phase. Wouldn’t it be a better<br>
> alternative to delay inlining decisions until the link stage?<br>
</div></div>Yes and no.<br>
Yes in the sense that you may make some better decisions.<br>
No in the sense that you will end up with larger modules (assuming<br>
some simple early CSE/etc is also done), and as a result of having<br>
done no inlining, may make worse decisions at the link stage inlining,<br>
depending on what IPA analysis you base your link stage inlining on<br>
and when it runs.<br>
<br>
It's certainly possible to have a link-phase only early inliner, and a<br>
link-phase only later inliner, and you will, in general, get better<br>
decisions than a local inliner + link phase inliner, but the cost you<br>
pay is more memory usage, more disk usage, etc.</blockquote><div><br></div><div>I'm curious -- where do you draw these conclusions from?</div><div><br></div><div>With the current LLVM inliner (significant portions of which are quite new) I would not expect bad decisions by delaying inlining until link time. In fact, there are a large number of heuristics we use during per-module inlining which make *zero* sense if you eventually perform LTO.</div>
<div><br></div><div>A very long-standing todo of mine is to build a per-module set of passes for LTO builds that is very carefully chosen to be information preserving and avoid decisions which can be better made at LTO-time. I suspect that we would see significantly better LTO results from this, but of course only an experiment will show. My hunch is because the optimization passes in LLVM have been heavily tuned for the information available in the per-module pass, and many of them will be ineffective if run after. The inliner is a good example here. We specifically evaluate potential future inlining opportunities when making a particular inlining decision. Doing that per-module when you will eventually have total information seems flawed.</div>
</div></div>