Re: [PATCH] Generic dead function optimisation

From: Graham Stoney (
Date: Tue Apr 25 2000 - 18:58:28 EST

Hi Andrew,

Andrew Morton writes:
> Sorry, Graham. I screwed up - got the compiler versions tangled, ended
> up compiling with You very sneakily determine whether the
> compiler supports -ffunction-sections and if not, fall back to the old
> behaviour.

Yes; makes it backwards compatible, but harder to ensure that it's kicking in.
Mind you, since I have to use KEEP in the .lds files, which was introduced to
help with --gc-sections, I don't know if the patch will work for folks with
very old (i.e. pre --gc-sections) binutils.


> An added bonus from this patch is that it allows ifdefs to be removed so
> that code can be always compiled, even if it's not required. This is a
> maintenance plus, preventing trivial mistakes from propagating.

Yes, it can mean less #ifdefs all round in fact. Unfortunately my
CONFIG_MESSAGES patch adds more, and the ext2 stuff is particularly unfriendly
because it's hard to optimise away the human-readable strings passed to the
error functions.

> Interesting that 'ld --gc-sections' takes about 15x longer than normal.

I haven't delved into this, but on PowerPC it takes no longer than normal, and
links in under a second. I think what you're seeing is platform specific.
Certainly we'd need to keep the x86 folks happy though, so we'd need to sort
this out.

> I would suggest that you make '-ffunction-sections/--gc-sections' _not_
> be the default behaviour - it's a concern that you're treading rarely
> travelled code paths through the compiler and linker. Perhaps add an
> experimental CONFIG_GC_FUNCTIONS?

As Alan pointed out, this particular road would benefit heavily from being more
travelled. I imagine it's likely to become the default settings for gcc
eventually anyway. I prefer automatic configuration wherever possible.

> I'm not sure that doing:
> ..
> #else
> #define printk(fmt, args...)
> #endif
> is the best approach. After all, printk() _does_ return an int,
> although you've proven that a lot of the kernel doesn't use this return
> value.

True, I haven't ever seen anyone check the result of printk, but I guess I
would be better to go:

#define printk(fmt, args...) 1 /* Non-zero is probably better */

> Perhaps:
> #else
> extern inline int printk(const char *s, ...)
> {
> return 0;
> }
> #endif

There's a reason I didn't do it this way: gcc-2.95.2 will still include the
format string in the .rodata section even though it optimises away the inlined
printk function. Eliminating the format strings is a significant part of the
savings in turning off CONFIG_MESSAGES, so the macro version is a bigger win.
I consider this a bug in gcc-2.95.2 which I might be able to get the gcc folks
to fix...


Graham Stoney
Principal Hardware/Software Engineer
Canon Information Systems Research Australia
Ph: +61 2 9805 2909  Fax: +61 2 9805 2929

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:10 EST