From: Jakub Jelinek <jakub@redhat.com>
To: Allan Sandfeld <linux@sneulv.dk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: kernel compiler
Date: Fri, 26 Oct 2001 05:35:03 -0400 [thread overview]
Message-ID: <20011026053503.U25384@devserv.devel.redhat.com> (raw)
In-Reply-To: <E15wmgp-0005E8-00@the-village.bc.nu> <3BD841B7.5060405@toughguy.net> <20011026001354.C2245@werewolf.able.es> <E15x38c-0000Dh-00@Princess>
In-Reply-To: <E15x38c-0000Dh-00@Princess>; from linux@sneulv.dk on Fri, Oct 26, 2001 at 11:18:46AM +0200
On Fri, Oct 26, 2001 at 11:18:46AM +0200, Allan Sandfeld wrote:
> > Last paragraph is the key. Perhaps previous gcc'd did not all his work
> > as the manual says (ie, did not kill the non-inline version, bug),
> > but people has got used to the bug, and see it as a feature.
>
> I believe '-fkeep-inline-functions' is your friend in this case. I haven't
> tested it though on the kernel.
Definitely not. -fkeep-inline-functions will not only prevent in compiler
eyes unused static functions from beeing optimized away, but you'll get tons
of code you really don't need.
__attribute__((used)) is what you can use in current gcc trunk to just say
the compiler that it should not optimize away a particular function even if
it seems to be unused at -O3 (e.g. it might be referenced from inline assembly,
whatever).
No matter what, using -O3 for kernel builds is a bad idea, in vast majority
functions which make sense to be inlined are in the kernel marked so with
inline keyword, and the rest does not. With -O3 for kernel you just get
bigger code with no gains (if there are some gains somewhere, then it should
be considered to be marked inline on a case by case basis).
Jakub
next prev parent reply other threads:[~2001-10-26 9:34 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-25 15:20 kernel compiler John Weber
2001-10-25 15:26 ` Axel
2001-10-25 15:45 ` Alan Cox
2001-10-25 16:45 ` Lost Logic
2001-10-25 17:16 ` Alan Cox
2001-10-25 22:00 ` J . A . Magallon
2001-10-25 22:13 ` J . A . Magallon
2001-10-26 9:18 ` Allan Sandfeld
2001-10-26 9:35 ` Jakub Jelinek [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-10-25 14:31 Frontgate Lab
2001-10-25 15:08 ` David Weinehall
2001-10-25 15:28 ` Alan Cox
2001-10-25 15:27 ` Steve Lord
2001-10-25 15:46 ` Jakub Jelinek
2001-10-25 15:45 ` Steve Lord
2000-11-03 21:19 Kernel compiler Ralf Baechle
2000-11-04 2:44 ` Keith Owens
2000-11-04 2:53 ` Ralf Baechle
2000-11-04 3:03 ` Keith M Wesolowski
2000-11-04 3:10 ` Pete Popov
2000-11-04 3:20 ` Ralf Baechle
2000-11-04 3:13 ` Keith Owens
2000-11-04 10:40 ` Alan Cox
2000-11-04 10:40 ` Alan Cox
2000-11-07 3:39 ` Ralf Baechle
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=20011026053503.U25384@devserv.devel.redhat.com \
--to=jakub@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@sneulv.dk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.