On Tue, Aug 28, 2012 at 10:39 PM, Daniel Berlin <dberlin at dberlin.org>
wrote:
> On Wed, Aug 29, 2012 at 12:11 AM, Ramanarayanan, Ramshankar
> <Ramshankar.Ramanarayanan at amd.com> wrote:
> > I am wondering how O4 vs O3 do inlining. With O4 it looks like
inlining
> is
> > done first on each file and then at linking phase. Wouldn’t it be a
> better
> > alternative to delay inlining decisions until the link stage?
> Yes and no.
> Yes in the sense that you may make some better decisions.
> No in the sense that you will end up with larger modules (assuming
> some simple early CSE/etc is also done), and as a result of having
> done no inlining, may make worse decisions at the link stage inlining,
> depending on what IPA analysis you base your link stage inlining on
> and when it runs.
>
> It's certainly possible to have a link-phase only early inliner, and a
> link-phase only later inliner, and you will, in general, get better
> decisions than a local inliner + link phase inliner, but the cost you
> pay is more memory usage, more disk usage, etc.
I'm curious -- where do you draw these conclusions from?
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120828/2311cf27/attachment.html>