From: Jakub Jelinek <jakub@redhat.com>
To: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
Cc: Robert Love <rml@tech9.net>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Dave Jones <davej@suse.de>
Subject: Re: Some functions are not inlined by gcc 3.2, resulting code is ugly
Date: Mon, 4 Nov 2002 06:39:17 -0500 [thread overview]
Message-ID: <20021104063917.G10988@devserv.devel.redhat.com> (raw)
In-Reply-To: <200211041112.gA4BCmp32103@Port.imtp.ilyichevsk.odessa.ua>; from vda@port.imtp.ilyichevsk.odessa.ua on Mon, Nov 04, 2002 at 02:04:42PM -0200
On Mon, Nov 04, 2002 at 02:04:42PM -0200, Denis Vlasenko wrote:
> Frankly, I'd say we should not inline anything large
> regardless of number of call sites, for reasons outlined above.
>
> The limit is designed exactly for this purpose I think.
But the limit doesn't work that way. First of all, the limit
ATM is O(tree nodes) where it is not known how many tree nodes
will be one instruction or how many instructions will one tree node expand
into. That all depends on the exact code being inlined and how well
can it be optimized. Nice example are kernel's constant stringop inlines.
And also, there is the problem with inlining from inlines, it may very well
happen that gcc will inline a big function which is almost at the limit
boundary, but then not inline any of tiny functions which should be inlined
in it.
As kernel is using inline explicitely and not -O3, I think best would be
to use bigger inline limit and remove inline keywords from big functions
which should not be inlined.
Of course, improving gcc tree inliner is very desirable too.
Jakub
next prev parent reply other threads:[~2002-11-04 11:33 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-03 16:17 Some functions are not inlined by gcc 3.2, resulting code is ugly Denis Vlasenko
2002-11-03 16:17 ` Jussi Laako
2002-11-04 0:17 ` Denis Vlasenko
2002-11-03 21:28 ` Jussi Laako
2002-11-04 16:00 ` Denis Vlasenko
2002-11-03 18:14 ` Denis Vlasenko
2002-11-03 15:23 ` Martin J. Bligh
2002-11-04 0:23 ` Denis Vlasenko
2002-11-03 15:37 ` Jakub Jelinek
2002-11-03 16:21 ` Alan Cox
2002-11-04 0:20 ` Denis Vlasenko
2002-11-03 20:28 ` Alan Cox
2002-11-04 16:08 ` Denis Vlasenko
2002-11-13 1:28 ` J.A. Magallón
2002-11-13 11:54 ` Denis Vlasenko
2002-11-13 12:48 ` Denis Vlasenko
2002-11-04 1:21 ` Robert Love
2002-11-04 13:41 ` Alan Cox
2002-11-04 22:44 ` Werner Almesberger
2002-11-04 16:04 ` Denis Vlasenko
2002-11-04 11:39 ` Jakub Jelinek [this message]
2002-11-13 0:10 ` J.A. Magallón
2002-11-13 12:04 ` Denis Vlasenko
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=20021104063917.G10988@devserv.devel.redhat.com \
--to=jakub@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=davej@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rml@tech9.net \
--cc=vda@port.imtp.ilyichevsk.odessa.ua \
/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