public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Rafael Espindola <espindola@google.com>
Cc: Diego Novillo <dnovillo@google.com>, Jan Hubicka <jh@suse.cz>,
		Jan Hubicka <hubicka@ucw.cz>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [lto][patch] Move the call to execute_all_ipa_transforms to  	cgraphunit.c
Date: Wed, 12 Nov 2008 16:02:00 -0000	[thread overview]
Message-ID: <20081112155106.GK27401@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <38a0d8450811120036h59cc4feaw9a92722ce4ca020d@mail.gmail.com>

> > OK, do you think you could implement this solution to extern inlines?
> > For now, running the inliner early will get rid of the immediate
> > problem we are having.  If you don't have a lot of time, could you
> > send an outline of what needs to be done?
> 
> I think I still prefer to run the inliner and drop the extern inline
> functions. The option of fully transferring then to wpa would be
> harder, since now the compiler would see more function bodies then the
> linker and would need decide what to do with them. I am afraid that
> converting extern inline into static functions would break some code
> that has unreasonable expectations about a function defined in another
> file being called.

Well, the scheme that I think would be ideal should work here.
Basically we should

 1) Make C and C++ froends to keep both copies of function of same name
 (extern inline and non-extern inline body) if available.
 2) Teach LTO to output the extern inlines as static functions and to
 direct all calls to extern inline function variant
 3) Teach inliner to redirect all the remaining calls to the externally
 visible body.  We aready do work on removing out of line extern inlines
 so this can be bundled there.

This should have precisely the intended semantics of extern inline
eliminating the current bug that extern inlines are ignored with
--combine and if offline body is present.

This (except for the LTO bits) is something on my TODO for years, but
I never got around implementing 1) correctly. 3) is very easy to do...
> 
> Doing an early inline (and possibly other optimizations) also has the
> benefit of reducing the size of the IL that is written to disk.

We already do this kind of early inline during the einline pass.
Einline pass is basically doing to work that pays back in both size and
speed and work that will be always done (always_inline and flatten
attribute processing), while full inliner is here to trade size for
speed based on knowledge of whole unit.

So you should not need to reorder passes here at all, just you will lose
some of extern inline oppurtunities (I think C frontend is making extern
inline always inline so early inliner will pick them except for weird
recursive cases where topological order does not allows them. In C++ I
think they are not always inline so early inliner will pick only very
small ones.  If you need immediate hack around, perhaps making C++ ones
to disregard inline limits too would work).

Honza
> 
> > Thanks.  Diego.
> >
> 
> Cheers,
> -- 
> Rafael Avila de Espindola
> 
> Google | Gordon House | Barrow Street | Dublin 4 | Ireland
> Registered in Dublin, Ireland | Registration Number: 368047

  reply	other threads:[~2008-11-12 15:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-11 17:31 Rafael Espindola
2008-11-11 20:23 ` Jan Hubicka
2008-11-11 22:49   ` Rafael Espindola
2008-11-11 22:53     ` Jan Hubicka
2008-11-11 23:11   ` Diego Novillo
2008-11-11 23:18     ` Jan Hubicka
2008-11-11 23:41       ` Rafael Espindola
2008-11-11 23:59         ` Jan Hubicka
2008-11-12  0:01           ` Diego Novillo
2008-11-12  0:04             ` Jan Hubicka
2008-11-12  0:57               ` Jan Hubicka
2008-11-12  2:02                 ` Diego Novillo
2008-11-12 10:01                   ` Rafael Espindola
2008-11-12 16:02                     ` Jan Hubicka [this message]
2008-11-12 16:35                   ` Jan Hubicka
2008-11-11 23:53       ` Diego Novillo
2008-11-11 22:54 ` Diego Novillo
2008-11-11 23:14   ` Jan Hubicka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081112155106.GK27401@atrey.karlin.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=dnovillo@google.com \
    --cc=espindola@google.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jh@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).