public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Jan Hubicka <hubicka@ucw.cz>, gcc-patches@gcc.gnu.org
Subject: Re: Relax limits of early inliner for the forwarder functions
Date: Tue, 08 Jan 2013 15:08:00 -0000	[thread overview]
Message-ID: <20130108150807.GA30388@kam.mff.cuni.cz> (raw)
In-Reply-To: <CAFiYyc2asDpR3vGkX6SsV_QCTbqRCAoHnWt1X3Fvm8tO64bO5g@mail.gmail.com>

> 
> So this counts all calls in the function we want to inline (!?).
> That's completely
> backward to me.  In fact for forwarder functions you still only allow half
> of the early-inlining-insns growth.  Previously for non-leafs we didn't allow
> any growth (hm, why?).

Well, the idea is that inlining leaf functions is almost always good idea
(i.e. you can assume that the function's body will optimize well with surrounding
code and eliminating a call is good thing)
Inlining functions that have call in it is less cool.  I introduced the non-leaf/leaf
logic in about 4.6 time after late inlining became more informed about anticipated
optimizations, but it really caused quite some trouble on C++ abstraction,
so relaxing this logic somewhat seemed like resonable idea.
> 
> Now with relaxing that and allowing functions with calls to be inlined more
> frequently we run into PR55797 which shows that we cannot limit recursive
> inlining anymore if it is indirect one level.  By means of early
> inlining iteration
> we blow up completely (8 iterations at most?!).  Also because we do not
> compute overall function growth (because we rely on early inlining only
> shrinking code size ...).

Well, we compute function growth, but for each iteratio nseparately.
> 
> I believe we at least need to track recursive inlining during early inliner
> iteration by means of some ->aux marking or so.

Hmm, I guess we want to disable recursive inlining in the early inliner completely.
I will take a look.

Honza
> 
> Honza - please have a look at the ICE in PR55797 and the issues with
> this patch enabling more inlining.
> 
> Thanks,
> Richard.
> 
> >         {
> >           if (dump_file)
> >             fprintf (dump_file, "  will not early inline: %s/%i->%s/%i, "
> > -                    "growth %i exceeds --param early-inlining-insns\n",
> > +                    "growth %i exceeds --param early-inlining-insns "
> > +                    "divided by number of calls\n",
> >                      xstrdup (cgraph_node_name (e->caller)), e->caller->uid,
> >                      xstrdup (cgraph_node_name (callee)), callee->uid,
> >                      growth);

      reply	other threads:[~2013-01-08 15:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-05 11:23 Jan Hubicka
2013-01-08 14:07 ` Richard Biener
2013-01-08 15:08   ` Jan Hubicka [this message]

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=20130108150807.GA30388@kam.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /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).