In discussions with akpm: it'd be nice to discard unused functions
(think CONFIG_PROC_FS=n) without needing to #ifdef around them.
Feedback welcome,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Name: Eliminate Unused Functions
Author: Rusty Russell
Status: Tested on 2.5.70-bk16
D: GCC 3.3 has the ability to eliminate unused static functions. This includes
D: code like this:
D:
D: static int unusedfunc(void) { ... };
D: int otherfunc(void)
D: {
D: (void)unusedfunc;
D: ...
D:
D: This means that macros can suppress the "unused" warning on functions
D: without preventing the function elimination. This should allow us to
D: remove a number of #ifdefs around unused functions.
D:
D: Unfortunately, this elimination is only performed if
D: -finline-functions is used. In order to prevent GCC automatically
D: inlining anything, we also specify "--param max-inline-insns-auto=0".
D:
D: Earlier compilers don't understand this parameter, so we test for
D: it at build time.
D:
D: Results (all with gcc 3.3)
D: Without patch:
D: -rwxrwxr-x 1 rusty rusty 5115166 Jun 13 09:17 vmlinux
D: With patch:
D: -rwxrwxr-x 1 rusty rusty 5115166 Jun 13 09:58 vmlinux
D: Without patch (small unused function added):
D: -rwxrwxr-x 1 rusty rusty 5115195 Jun 13 10:14 vmlinux
D: With patch (small unused function added):
D: -rwxrwxr-x 1 rusty rusty 5115166 Jun 13 10:15 vmlinux
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal working-2.5.70-bk16-check_region/Makefile working-2.5.70-bk16-check_region-inline/Makefile
--- working-2.5.70-bk16-check_region/Makefile 2003-06-12 09:57:39.000000000 +1000
+++ working-2.5.70-bk16-check_region-inline/Makefile 2003-06-12 21:34:40.000000000 +1000
@@ -213,10 +213,13 @@ CFLAGS_KERNEL =
AFLAGS_KERNEL =
NOSTDINC_FLAGS = -nostdinc -iwithprefix include
+# Needs gcc 3.3 or above to understand max-inline-insns-auto.
+INLINE_OPTS := $(shell $(CC) -o /non/existent/file -c --param max-inline-insns-auto=0 -xc /dev/null 2>&1 | grep /non/existent/file >/dev/null && echo -finline-functions --param max-inline-insns-auto=0)
+-finline-functions --param max-inline-insns-auto=0
CPPFLAGS := -D__KERNEL__ -Iinclude
CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \
- -fno-strict-aliasing -fno-common
+ $(INLINE_OPTS) -fno-strict-aliasing -fno-common
AFLAGS := -D__ASSEMBLY__ $(CPPFLAGS)
export VERSION PATCHLEVEL SUBLEVEL EXTRAVERSION KERNELRELEASE ARCH \
Argh, bogus line pasted into Makefile turned up in patch.
This should be better...
Name: Eliminate Unused Functions
Author: Rusty Russell
Status: Tested on 2.5.70-bk16
D: GCC 3.3 has the ability to eliminate unused static functions. This includes
D: code like this:
D:
D: static int unusedfunc(void) { ... };
D: int otherfunc(void)
D: {
D: (void)unusedfunc;
D: ...
D:
D: This means that macros can suppress the "unused" warning on functions
D: without preventing the function elimination. This should allow us to
D: remove a number of #ifdefs around unused functions.
D:
D: Unfortunately, this elimination is only performed if
D: -finline-functions is used. In order to prevent GCC automatically
D: inlining anything, we also specify "--param max-inline-insns-auto=0".
D:
D: Earlier compilers don't understand this parameter, so we test for
D: it at build time.
D:
D: Results:
D: gcc 3.3 without patch:
D: -rwxrwxr-x 1 rusty rusty 5115166 Jun 13 09:17 vmlinux
D: gcc 3.3 with patch:
D: -rwxrwxr-x 1 rusty rusty 5115166 Jun 13 09:58 vmlinux
D: gcc 3.3 without patch (small unused function added):
D: -rwxrwxr-x 1 rusty rusty 5115195 Jun 13 10:14 vmlinux
D: gcc 3.3 with patch (small unused function added):
D: -rwxrwxr-x 1 rusty rusty 5115166 Jun 13 10:15 vmlinux
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal working-2.5.70-bk16-check_region/Makefile working-2.5.70-bk16-check_region-inline/Makefile
--- working-2.5.70-bk16-check_region/Makefile 2003-06-12 09:57:39.000000000 +1000
+++ working-2.5.70-bk16-check_region-inline/Makefile 2003-06-12 21:34:40.000000000 +1000
@@ -213,10 +213,12 @@ CFLAGS_KERNEL =
AFLAGS_KERNEL =
NOSTDINC_FLAGS = -nostdinc -iwithprefix include
+# Needs gcc 3.3 or above to understand max-inline-insns-auto.
+INLINE_OPTS := $(shell $(CC) -o /non/existent/file -c --param max-inline-insns-auto=0 -xc /dev/null 2>&1 | grep /non/existent/file >/dev/null && echo -finline-functions --param max-inline-insns-auto=0)
CPPFLAGS := -D__KERNEL__ -Iinclude
CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \
- -fno-strict-aliasing -fno-common
+ $(INLINE_OPTS) -fno-strict-aliasing -fno-common
AFLAGS := -D__ASSEMBLY__ $(CPPFLAGS)
export VERSION PATCHLEVEL SUBLEVEL EXTRAVERSION KERNELRELEASE ARCH \
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
In article <[email protected]> you wrote:
> D: Results (all with gcc 3.3)
> D: Without patch:
> D: -rwxrwxr-x 1 rusty rusty 5115166 Jun 13 09:17 vmlinux
> D: With patch:
> D: -rwxrwxr-x 1 rusty rusty 5115166 Jun 13 09:58 vmlinux
> D: Without patch (small unused function added):
> D: -rwxrwxr-x 1 rusty rusty 5115195 Jun 13 10:14 vmlinux
> D: With patch (small unused function added):
> D: -rwxrwxr-x 1 rusty rusty 5115166 Jun 13 10:15 vmlinux
does that mean the current linux source tree does not benefit in any way
from this patch?
Greetings
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
Bernd Eckenfels wrote:
> does that mean the current linux source tree does not benefit in any way
> from this patch?
I suspect that currently all such instances are wrapped in #ifdef and are not
currently compiled in. As he said in the original message, "it'd be nice to
discard unused functions (think CONFIG_PROC_FS=n) without needing to #ifdef
around them."
This would allow us to remove those #ifdefs.
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
On Fri, Jun 13, 2003 at 10:04:56AM -0400, Chris Friesen wrote:
> Bernd Eckenfels wrote:
>
> >does that mean the current linux source tree does not benefit in any way
> >from this patch?
>
> I suspect that currently all such instances are wrapped in #ifdef and are
> not currently compiled in. As he said in the original message, "it'd be
> nice to discard unused functions (think CONFIG_PROC_FS=n) without needing
> to #ifdef around them."
>
> This would allow us to remove those #ifdefs.
... only if we say a min gcc version of 3.3 however, yes? Otherwise the
kernel gets rather bloated. Just how wide-spread (and Good To Use) is
gcc-3.3 now?
--
Tom Rini
http://gate.crashing.org/~trini/
On Fri, 2003-06-13 at 09:03, Tom Rini wrote:
> ... only if we say a min gcc version of 3.3 however, yes? Otherwise the
> kernel gets rather bloated. Just how wide-spread (and Good To Use) is
> gcc-3.3 now?
Good point.
I have been using gcc-3.3 for awhile now with success, and I can
recommend it at least for x86, but that really is not reason to force
anyone to move to it (yet).
So this change will be nice when gcc 3.3 or greater is the minimum
compiler, but not very nice until then. If we start eradicating ifdefs
users of older compilers will get very bloated kernels.
I would also like it if we did not have to do the hackish inling
stuff...
Robert Love
On Fri, Jun 13, 2003 at 11:07:19AM -0700, Robert Love wrote:
> On Fri, 2003-06-13 at 09:03, Tom Rini wrote:
>
> > ... only if we say a min gcc version of 3.3 however, yes? Otherwise the
> > kernel gets rather bloated. Just how wide-spread (and Good To Use) is
> > gcc-3.3 now?
>
> Good point.
>
> I have been using gcc-3.3 for awhile now with success, and I can
> recommend it at least for x86, but that really is not reason to force
> anyone to move to it (yet).
But how much have you rebuilt, heavily tested, etc? I know that
currently Debian/sid is building XFree86 4.1 at -O on all arches due to
gcc-3.3 issues (some xdm auth problem on ppc and x86, other things
elsewhere).
> So this change will be nice when gcc 3.3 or greater is the minimum
> compiler, but not very nice until then. If we start eradicating ifdefs
> users of older compilers will get very bloated kernels.
Indeed.
--
Tom Rini
http://gate.crashing.org/~trini/
On Fri, 2003-06-13 at 18:15, Tom Rini wrote:
> But how much have you rebuilt, heavily tested, etc? I know that
> currently Debian/sid is building XFree86 4.1 at -O on all arches due to
> gcc-3.3 issues (some xdm auth problem on ppc and x86, other things
> elsewhere).
I believe Red Hat Rawhide (what I am running) is built with gcc 3.3.
Anyhow, my point was we _don't_ know if its ready so we cannot start
doing things which are detrimental to users of earlier kernels. I was
just adding that it does seem to compile the kernel fine for me, at
least.
Robert Love
On Fri, Jun 13, 2003 at 11:15:16AM -0700, Tom Rini wrote:
> On Fri, Jun 13, 2003 at 11:07:19AM -0700, Robert Love wrote:
> > On Fri, 2003-06-13 at 09:03, Tom Rini wrote:
> >
> > > ... only if we say a min gcc version of 3.3 however, yes? Otherwise the
> > > kernel gets rather bloated. Just how wide-spread (and Good To Use) is
> > > gcc-3.3 now?
> >
> > Good point.
> >
> > I have been using gcc-3.3 for awhile now with success, and I can
> > recommend it at least for x86, but that really is not reason to force
> > anyone to move to it (yet).
>
> But how much have you rebuilt, heavily tested, etc? I know that
> currently Debian/sid is building XFree86 4.1 at -O on all arches due to
s/4.1/4.2.1/
> gcc-3.3 issues (some xdm auth problem on ppc and x86, other things
> elsewhere).
>...
> Tom Rini
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, Jun 13, 2003 at 11:03:43AM +1000, Rusty Russell wrote:
> Argh, bogus line pasted into Makefile turned up in patch.
>
> This should be better...
>...
> +# Needs gcc 3.3 or above to understand max-inline-insns-auto.
> +INLINE_OPTS := $(shell $(CC) -o /non/existent/file -c --param max-inline-insns-auto=0 -xc /dev/null 2>&1 | grep /non/existent/file >/dev/null && echo -finline-functions --param max-inline-insns-auto=0)
>...
You have to add a -Wno-unused-function or you'll get a warning for every
eliminated function.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, 13 June 2003 09:03:35 -0700, Tom Rini wrote:
>
> ... only if we say a min gcc version of 3.3 however, yes? Otherwise the
> kernel gets rather bloated. Just how wide-spread (and Good To Use) is
> gcc-3.3 now?
I haven't seen a clear compiler bug yet, but found two bugs in
assembler code with 2.95.3 that compiled without problems with 3.2.x.
One of them has actually hit people, as you could see in the code.
Most symptoms were "fixed", but the cause remained.
If nothing else, I'd like to keep 2.95 as a code checker for at least
a year or two. Give 3.x some more time to mature.
J?rn
--
Measure. Don't tune for speed until you've measured, and even then
don't unless one part of the code overwhelms the rest.
-- Rob Pike
J?rn Engel wrote:
> I haven't seen a clear compiler bug yet, but found two bugs in
> assembler code with 2.95.3 that compiled without problems with 3.2.x.
> One of them has actually hit people, as you could see in the code.
> Most symptoms were "fixed", but the cause remained.
Another data point... Earlier (I *think* it was this thread) someone
mentioned problems with trying to build glibc with gcc 3.x and "ls"
segfaulting. I've recently upgraded portions of my system (including
libraries and compilers) with the packages from the Slackware 9.0 CD.
I expect a certain amount of pain (due to library version conflicts)
every time I go through the upgrade process, but this time the pain
feels different... I absolutely cannot get getty and uugetty from the
getty-ps-2.1.0 package to work: segmentation faults. Even tried building
from source: no good. My old getty and uugetty binaries (version 2.0.7j)
seem to work ok with the new libraries, but rebuilding the 2.0.7j code
with gcc-3.2.2 results in segfaults.
The behavior seems to be independent of kernel version (2.5.70-2.5.72).
Here's the relevant version list (referenced libraries reported by ldd):
kernel 2.5.72
glibc 2.3.1
libtermcap 2.0.8
ld-2.3.1
gcc 3.2.2
binutils 2.13.90.0.18
The Slackware default install uses agetty rather than the getty-ps
package, which may partly explain why my particular symptom hasn't been
reported previously (to my knowledge). I'm curious to know if this
problem exists with a virgin Slackware 9 installation, and will probably
have an answer by this weekend, time permitting.
--
-----------------------------------------------------------------------
Bob Tracy WTO + WIPO = DMCA? http://www.anti-dmca.org
[email protected]
-----------------------------------------------------------------------
Bob Tracy wrote:
> Another data point... Earlier (I *think* it was this thread) someone
> mentioned problems with trying to build glibc with gcc 3.x and "ls"
> segfaulting. I've recently upgraded portions of my system (including
> libraries and compilers) with the packages from the Slackware 9.0 CD.
> I expect a certain amount of pain (due to library version conflicts)
> every time I go through the upgrade process, but this time the pain
> feels different... I absolutely cannot get getty and uugetty from the
> getty-ps-2.1.0 package to work: segmentation faults. Even tried building
> from source: no good. My old getty and uugetty binaries (version 2.0.7j)
> seem to work ok with the new libraries, but rebuilding the 2.0.7j code
> with gcc-3.2.2 results in segfaults.
That was me, but it wasn't this thread. I was talking about building
glibc against the 2.5.x kernel headers, that caused problems. glibc
2.3.2 with gcc 3.3 against the 2.4.20 headers is perfectly stable, and
passes all tests in "make check". Even with "-O3 -march=athlon-xp
-mfpmath=sse", the only tests that fail are in the trig functions (SSE
on the Althon only has 32 bit precision so the values are truncated).
--
Chris
In message <[email protected]> you write:
> On Fri, Jun 13, 2003 at 11:03:43AM +1000, Rusty Russell wrote:
> > Argh, bogus line pasted into Makefile turned up in patch.
> >
> > This should be better...
> >...
> > +# Needs gcc 3.3 or above to understand max-inline-insns-auto.
> > +INLINE_OPTS := $(shell $(CC) -o /non/existent/file -c --param max-i
nline-insns-auto=0 -xc /dev/null 2>&1 | grep /non/existent/file >/dev/null && e
cho -finline-functions --param max-inline-insns-auto=0)
> >...
>
> You have to add a -Wno-unused-function or you'll get a warning for every
> eliminated function.
No, suppressing warnings like that would be bad. Instead, you write
functions like this:
#ifdef CONFIG_FOO
extern int register_foo(foo_fn myfunction);
#else
static inline int register_foo(foo_fn myfunction)
{
return 0;
}
#endif /* CONFIG_FOO */
That way, there's no unused warning, but gcc knows enough to discard
the function.
Hope that clarifies!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.