Re: [2.6 patch] add a config option for -Os compilation

Re: [2.6 patch] add a config option for -Os compilation

[Ihar 'Philips' Filipau]

Martin J. Bligh wrote:
> If you have a puny 128K L2 cache, it might help,

   [ I accept this as a flame-bait. ]
   Can you be little bit less ignorant? Eh?
   Please. I beg you.
   Linux is used not only by you, and not only on huge NUMA boxes with 
huge caches <flame-bait>to hide stupid design flaws</flame-bait>. (can't 
wait when clusters of hand-helds connected over bluetooth will wipe out 
mainframe market :)))

   My system has 16K L1 cache. Only L1. And what should I do?
   I was benchmarking 2.4.1[68] some time ago and -Os helps gcc to 
produce faster code (both gcc 2.95.3 and 3.2.3). (It was Geode. But e.g. 
Motorolla's PowerQuicc has 16K L1 too - but I'm not sure does -Os help 
on ppc)

   On my test difference was around 5-7%. Task was very IO intensive 
with few of computational branches. Size of .text ~ 800K, .bss ~ 400K.

> Please don't - I benchmarked it a while ago, and it's definitely slower.
> If you have a puny 128K L2 cache, it might help, but it definitely needs
> to be optional.

   Optional - would be Okay.

P.S. That's dependency on GCC what should be optional. Let's not forget 
the source of the problem.

-- 
Ihar 'Philips' Filipau  / with best regards from Saarbruecken.
--
   "... and for $64000 question, could you get yourself vaguely
      familiar with the notion of on-topic posting?"
				-- Al Viro @ LKML

Re: [2.6 patch] add a config option for -Os compilation

[Ihar 'Philips' Filipau]

Adrian Bunk wrote:
> On Sat, Oct 18, 2003 at 07:10:22PM +0200, Ihar 'Philips' Filipau wrote:
> 
>>Martin J. Bligh wrote:
>>>If you have a puny 128K L2 cache, it might help,
> 
> Martin was ironically talking about people who are ignorant of machines
> with _huge_ caches.
> 

   Oh. Sorry. Probably I need to work on my English bit more.

> I the context of this thread he wanted to vote for making -Os 
> conditionally and not unconditionally enabled by telling that he knows 
> of situations where -O2 produces faster code.

   Absolutely.
   High-end toys, after all, optimized to handle this.

   IMHO this should be settled on per-target basis: embedded system - 
-Os; servers - -O2; desktops - -O3 ;) So instead of CONFIG_EMBEDDED 
better to have CONFIG_TARGET=[desktop|server|embedded].

   Inroducing one more variable into builds - is really painful. I was 
hit by gcc miscompiles and internal errors not once (especially with 
-O[23]). Tracking down this kind of issues would be made more problematic.

P.S. I'm really sorry for my rude response.

-- 
Ihar 'Philips' Filipau  / with best regards from Saarbruecken.
--
   "... and for $64000 question, could you get yourself vaguely
      familiar with the notion of on-topic posting?"
				-- Al Viro @ LKML

Re: [2.6 patch] add a config option for -Os compilation

[Martin J. Bligh]

>> Martin was ironically talking about people who are ignorant of machines
>> with _huge_ caches.
>> 
> 
>    Oh. Sorry. Probably I need to work on my English bit more.
> 
>> I the context of this thread he wanted to vote for making -Os 
>> conditionally and not unconditionally enabled by telling that he knows 
>> of situations where -O2 produces faster code.
> 
>    Absolutely.
>    High-end toys, after all, optimized to handle this.
> 
>    IMHO this should be settled on per-target basis: embedded system - -Os; servers - -O2; desktops - -O3 ;) So instead of CONFIG_EMBEDDED better to have CONFIG_TARGET=[desktop|server|embedded].
> 
>    Inroducing one more variable into builds - is really painful. I was hit by gcc miscompiles and internal errors not once (especially with -O[23]). Tracking down this kind of issues would be made more problematic.
> 
> P.S. I'm really sorry for my rude response.

;-) No problem. 

But if someone with a small cache would actually *measure* the damned 
thing, I'd be more impressed ... I've never seen that, but perhaps
I just missed it. 

Point is the same either way though ... we shouldn't unconditionally
optimise for *anyone's* system. If it's faster on all systems that anyone
can be bothered to measure, great. If it's faster on some, and slower on
others, a config option seems more appropriate, defaulting to the majority
of users.

M.

Re: [2.6 patch] add a config option for -Os compilation

[Ihar 'Philips' Filipau]

Ihar 'Philips' Filipau wrote:
> Wichert Akkerman wrote:
> 
>> Previously Ihar 'Philips' Filipau wrote:
>>
>>>  The goal of kernel is to provide framework for applications to the 
>>> job well.
>>
>>
>> I doubt anyone using linux for routing would agree with you.
>>
> 
>   This is different matter.
>   This is IO bound task - and I'm not sure how -Os will perform there.
>   But still this depends on routing protocols and their requirements.
> 
>   In any way in this case bottleneck is PCI bus (DMA over PCI from NIC 
> to main memory and back). I bet software will show up in timing tests as 
> taking <10% of whole time.
> 

   Sorry I mean't calculations and alike will take <10%.
   Sure in case of software router 90% of time will be spent in CPU.

-- 
Ihar 'Philips' Filipau  / with best regards from Saarbruecken.
--
   "... and for $64000 question, could you get yourself vaguely
      familiar with the notion of on-topic posting?"
				-- Al Viro @ LKML

Re: [2.6 patch] add a config option for -Os compilation

[Ihar 'Philips' Filipau]

Wichert Akkerman wrote:
> Previously Ihar 'Philips' Filipau wrote:
> 
>>  The goal of kernel is to provide framework for applications to the 
>>job well.
> 
> I doubt anyone using linux for routing would agree with you.
> 

   This is different matter.
   This is IO bound task - and I'm not sure how -Os will perform there.
   But still this depends on routing protocols and their requirements.

   In any way in this case bottleneck is PCI bus (DMA over PCI from NIC 
to main memory and back). I bet software will show up in timing tests as 
taking <10% of whole time.

-- 
Ihar 'Philips' Filipau  / with best regards from Saarbruecken.
--
   "... and for $64000 question, could you get yourself vaguely
      familiar with the notion of on-topic posting?"
				-- Al Viro @ LKML

Re: [2.6 patch] add a config option for -Os compilation

[Ihar 'Philips' Filipau]

Martin J. Bligh wrote:
> 
> But if someone with a small cache would actually *measure* the damned 
> thing, I'd be more impressed ... I've never seen that, but perhaps
> I just missed it. 
> 
> Point is the same either way though ... we shouldn't unconditionally
> optimise for *anyone's* system. If it's faster on all systems that anyone
> can be bothered to measure, great. If it's faster on some, and slower on
> others, a config option seems more appropriate, defaulting to the majority
> of users.
> 

   The thing is, that in fact kernel optimization is not that important.

   The goal of kernel is to provide framework for applications to the 
job well. I wasn't doing any kernels measurements - since kernel docs 
are saying that -O2 is the standard. And it is really hard to measure 
kernel only perfomance. (And it is rather pointless - I'm not going to 
sell linux kernel ;-)))

   But indeed I was testing my application on embedded system with 16K 
L1 cache. Results were pretty predictable: gcc 2.95.3 + -Os was giving 
some (around 2-3%) performance improvements, while 2.95.3 + -O[23] and 
3.2.3 with any optimization were giving aprox. the same times. (App is 
bloated with third-party libraries, C++ and threads. Save God I have 
killed all exceptions - they were really really really slow on target 
system.)

   But on other side - since embedded systems are not that overclocked 
as high-end toys - cache miss is not that painful. As of docs, NatSemi 
Geode@266MHz cache miss costs exactly 266/66 == 4 cycles.

-- 
Ihar 'Philips' Filipau  / with best regards from Saarbruecken.
--
   "... and for $64000 question, could you get yourself vaguely
      familiar with the notion of on-topic posting?"
				-- Al Viro @ LKML

Re: [2.6 patch] add a config option for -Os compilation

[Wichert Akkerman]

Previously Ihar 'Philips' Filipau wrote:
>   The goal of kernel is to provide framework for applications to the 
> job well.

I doubt anyone using linux for routing would agree with you.

Wichert.

-- 
Wichert Akkerman <wichert@wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

Re: [2.6 patch] add a config option for -Os compilation

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

On Sun, 19 Oct 2003 18:14:55 +0200, Wichert Akkerman <wichert@wiggy.net>  said:
> Previously Ihar 'Philips' Filipau wrote:
> >   The goal of kernel is to provide framework for applications to the 
> > job well.
> 
> I doubt anyone using linux for routing would agree with you.

OK, so the applications are limited to /sbin/iptables, /sbin/route, /bin/
netstat, and maybe dhcpd and/or zebra. They're still applications, even if they
end up invoking a lot of kernel resources on their behalf.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [2.6 patch] add a config option for -Os compilation

[Maciej Zenczykowski]

> OK, so the applications are limited to /sbin/iptables, /sbin/route, /bin/
> netstat, and maybe dhcpd and/or zebra. They're still applications, even if they
> end up invoking a lot of kernel resources on their behalf.

/sbin/iptables and /sbin/route are merely configuration interfaces to the 
kernel proper, not really familiar with netstat - but as far as I know all 
it does is dumps kernel runtime configuration and statistics.  That's 3 
utilities which are no way apps - just interfaces.  Now dhcpd is an app 
and zebra is an app - but they are still mainly kernel oriented.  The 
first 3 depend only on kernel speed and the next 2 depend mostly on kernel 
speed.  I'd say you just proved how important kernel optimilization is for 
routers.

Cheers,
MaZe.

Re: [2.6 patch] add a config option for -Os compilation

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]

On Sun, 19 Oct 2003 18:57:05 +0200, Maciej Zenczykowski said:

> and zebra is an app - but they are still mainly kernel oriented.  The 
> first 3 depend only on kernel speed and the next 2 depend mostly on kernel 
> speed.  I'd say you just proved how important kernel optimilization is for 
> routers.

And we had a flame-fest a while ago about poll/epoll/etc and how optimizing
that is important for some applications., and discussions of how CPU scheduling
affects desktop applications, and how different I/O schedulers matter to
databases, and....

My point was that the kernel is there for the application's benefit (otherwise
we could have just said 'echo "main() { for(;;){}}" > linux.c' and been done
with it), and just because the iptables or route command say "do this" and
return, and the kernel is still "doing this" weeks later, doesn't change the
fact that it's happening at the application's request (although you *are*
correct that the tuning and optimization concerns are different).


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [2.6 patch] add a config option for -Os compilation

[Andi Kleen]

Andrew Morton <akpm@osdl.org> writes:

> And bear in mind that you can see significant changes in benchmark results
> between equivalent kernels even when the optimisation level is kept the
> same, due to aliasing and alignment luck.

It also depends on a lot on the compiler version. On 2.95 
it was common wisdom that -Os is often fastest, but that changed
in later versions.

Best would be actually a mix of both - setting it case by case.
That's already done in specific cases, e.g. ACPI is always compiled
with -Os. This could be done for other files which are clearly
slow path too.

Profile feedback is unfortunately not an option because it is too
unpredictable and causes maintenance problems.

-Andi

Re: [2.6 patch] add a config option for -Os compilation

[Ingo Oeser]

Hi all,

On Saturday 18 October 2003 21:19, Andi Kleen wrote:
> Best would be actually a mix of both - setting it case by case.
> That's already done in specific cases, e.g. ACPI is always compiled
> with -Os. This could be done for other files which are clearly
> slow path too.

If there is is guarantee fro the GCC Steering Comitee, that there will
never be any ABI changes generated from the differences there (like
structure padding on/off).

Maybe there should be sth. in the build system for that, which is called
$(call optimize_for_speed, $target) and $(call optimize_for_size,$target) 
which then can be added on a per file basis and per directory tree,
where it really matters and letting it to the default otherwise.

That way we can tune gradually and remove GCC options.

Simple implementation today:

optimize_for_speed := CFLAGS_$1 += -O3
optimize_for_size  := CFLAGS_$1 += -Os


Sam: What do you think?

Regards

Ingo Oeser

Re: [2.6 patch] add a config option for -Os compilation

[Michael Buesch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 19 October 2003 15:56, Ingo Oeser wrote:
> Hi all,

Hi Ingo

> Simple implementation today:
>
> optimize_for_speed := CFLAGS_$1 += -O3
> optimize_for_size  := CFLAGS_$1 += -Os

I experienced many problems while using -O3,
because it may randomly inline functions, that
are not marked inline. For example -O3 made
ide-scsi on 2.4 nonworking for me.
The book "Linux Device Drivers" has a longer
explanation for _not_ using -O3 on kernels.

>
> Regards
>
> Ingo Oeser

- -- 
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/kpsfoxoigfggmSgRAgKEAJ9VwoVGyaP3qIm+RT0o3Q9pAhxMYgCeMz9f
vLJH6H+xM1yXfKXaXg2IPF8=
=oQIW
-----END PGP SIGNATURE-----

Re: [2.6 patch] add a config option for -Os compilation

[Sam Ravnborg]

On Sun, Oct 19, 2003 at 03:56:56PM +0200, Ingo Oeser wrote:
> Maybe there should be sth. in the build system for that, which is called
> $(call optimize_for_speed, $target) and $(call optimize_for_size,$target) 
> which then can be added on a per file basis and per directory tree,
> where it really matters and letting it to the default otherwise.
> 
> That way we can tune gradually and remove GCC options.
> 
> Simple implementation today:
> 
> optimize_for_speed := CFLAGS_$1 += -O3
> optimize_for_size  := CFLAGS_$1 += -Os
> 
> 
> Sam: What do you think?

Focussing on -O2 versus -Os is too narrowscoped for the build system.
A much more general solution is needed, without loosing the flexibility
we have today.
For 2.7 I have planned making it possible to modify CFLAGS, and make the
change be effective for all recursive builds.
This could be usefull if for example acpi decides to use -Werror for
all files. One change in one makefile and the desired effect is achieved.
The same infrastructure will be possible to use for -Owhatever.

We sould stick with -O2 for 2.6, lets play with other settings for 2.7.
Router people and others with special needs can finetune it at will in
2.6 - it is one line in the top-level makefile so not a big deal.

	Sam

[2.6 patch] add a config option for -Os compilation

[Adrian Bunk]

Hi Andrew,

the patch below adds a configuration option for -Os (the H8300 symbol is
similar to the symbols on other architectures). It includes the results
of all detail discussions and applies, compiles and works with
2.6.0-test7-mm1.

Could you add it to -mm?

diffstat output:

 Makefile            |    8 +++++++-
 arch/arm/Makefile   |    2 --
 arch/h8300/Kconfig  |    4 ++++
 arch/h8300/Makefile |    3 +--
 init/Kconfig        |   10 ++++++++++
 5 files changed, 22 insertions(+), 5 deletions(-)


TIA
Adrian


--- linux-2.6.0-test5-mm4/init/Kconfig.old	2003-09-25 14:38:18.000000000 +0200
+++ linux-2.6.0-test5-mm4/init/Kconfig	2003-09-25 14:47:12.000000000 +0200
@@ -65,6 +65,16 @@
 
 menu "General setup"
 
+config CC_OPTIMIZE_FOR_SIZE
+	bool "Optimize for size" if EXPERIMENTAL
+	default y if ARM || H8300
+	default n
+	help
+	  Enabling this option will pass "-Os" instead of "-O2" to gcc
+	  resulting in a smaller kernel.
+
+	  If unsure, say N.
+
 config SWAP
 	bool "Support for paging of anonymous memory"
 	depends on MMU
--- linux-2.6.0-test5-mm4/Makefile.old	2003-09-25 14:38:18.000000000 +0200
+++ linux-2.6.0-test5-mm4/Makefile	2003-09-25 14:40:26.000000000 +0200
@@ -274,7 +274,7 @@
 CPPFLAGS        := -D__KERNEL__ -Iinclude \
 		   $(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include)
 
-CFLAGS 		:= -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \
+CFLAGS 		:= -Wall -Wstrict-prototypes -Wno-trigraphs \
 	  	   -fno-strict-aliasing -fno-common
 AFLAGS		:= -D__ASSEMBLY__
 
@@ -421,6 +421,12 @@
 # ---------------------------------------------------------------------------
 
 
+ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
+CFLAGS		+= -Os
+else
+CFLAGS		+= -O2
+endif
+
 ifndef CONFIG_FRAME_POINTER
 CFLAGS		+= -fomit-frame-pointer
 endif
--- linux-2.6.0-test5-mm4/arch/arm/Makefile.old	2003-09-25 14:38:18.000000000 +0200
+++ linux-2.6.0-test5-mm4/arch/arm/Makefile	2003-09-25 14:40:47.000000000 +0200
@@ -14,8 +14,6 @@
 GZFLAGS		:=-9
 #CFLAGS		+=-pipe
 
-CFLAGS		:=$(CFLAGS:-O2=-Os)
-
 ifeq ($(CONFIG_FRAME_POINTER),y)
 CFLAGS		+=-fno-omit-frame-pointer -mapcs -mno-sched-prolog
 endif
--- linux-2.6.0-test5-mm4/arch/h8300/Kconfig.old	2003-09-25 14:43:27.000000000 +0200
+++ linux-2.6.0-test5-mm4/arch/h8300/Kconfig	2003-09-25 14:43:44.000000000 +0200
@@ -5,6 +5,10 @@
 
 mainmenu "uClinux/h8300 (w/o MMU) Kernel Configuration"
 
+config H8300
+	bool
+	default y
+
 config MMU
 	bool
 	default n
--- linux-2.6.0-test5-mm4/arch/h8300/Makefile.old	2003-09-25 14:38:18.000000000 +0200
+++ linux-2.6.0-test5-mm4/arch/h8300/Makefile	2003-09-25 14:38:24.000000000 +0200
@@ -34,7 +34,7 @@
 ldflags-$(CONFIG_CPU_H8S)	:= -mh8300self
 
 CFLAGS += $(cflags-y)
-CFLAGS += -mint32 -fno-builtin -Os
+CFLAGS += -mint32 -fno-builtin
 CFLAGS += -g
 CFLAGS += -D__linux__
 CFLAGS += -DUTS_SYSNAME=\"uClinux\"

Re: [2.6 patch] add a config option for -Os compilation

[Andrew Morton]

Adrian Bunk <bunk@fs.tum.de> wrote:
>
> the patch below adds a configuration option for -Os

Two problems:

a) It adds yet another reason why person A discovers problems which
   person B cannot reproduce.

b) It adds yet another reason why person A cannot work out the exact
   file-n-line where person B's kernel oopsed.

They are small concerns really, but it does make one wonder why we should
not make this change unconditional: just switch the kernel to -Os?

Does anyone have any (non-micro-)benchmark results which say this is a bad
idea?

Re: [2.6 patch] add a config option for -Os compilation

[Adrian Bunk]

On Wed, Oct 15, 2003 at 04:12:51PM -0700, Andrew Morton wrote:
>...
> They are small concerns really, but it does make one wonder why we should
> not make this change unconditional: just switch the kernel to -Os?
> 
> Does anyone have any (non-micro-)benchmark results which say this is a bad
> idea?

No benchmarks, only arguments:

- it's less tested (there might be miscompilations in some part of the 
  kernel with some supported compilers)
- there might be fast path code somewhere in the kernel that becomes
  significantely slower with -Os
- I've already seen a report for an ICE in gcc 2.95 of a user compiling
  kernel 2.4 with -Os [1]

cu
Adrian

[1] http://bugs.debian.org/213497

-- 

       "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

Re: [2.6 patch] add a config option for -Os compilation

[Andrew Morton]

Adrian Bunk <bunk@fs.tum.de> wrote:
>
> On Wed, Oct 15, 2003 at 04:12:51PM -0700, Andrew Morton wrote:
> >...
> > They are small concerns really, but it does make one wonder why we should
> > not make this change unconditional: just switch the kernel to -Os?
> > 
> > Does anyone have any (non-micro-)benchmark results which say this is a bad
> > idea?
> 
> No benchmarks, only arguments:
> 
> - it's less tested (there might be miscompilations in some part of the 
>   kernel with some supported compilers)

Testing is not a problem.

> - there might be fast path code somewhere in the kernel that becomes
>   significantely slower with -Os

I really doubt it.  Kernel CPU footprint is dominated by dcache misses.  If
-Os reduces icache footprint it may even be a net win; people tend to
benchmark things in tight loops, which favours fast code over small code.

> - I've already seen a report for an ICE in gcc 2.95 of a user compiling
>   kernel 2.4 with -Os [1]

Well there's only one way to find out if we'll hit that.  How's about you
cook me a patch which switches to -Os unconditionally and we'll see how it
goes?

Re: [2.6 patch] add a config option for -Os compilation

[Adrian Bunk]

On Wed, Oct 15, 2003 at 04:52:05PM -0700, Andrew Morton wrote:
>...
> I really doubt it.  Kernel CPU footprint is dominated by dcache misses.  If
> -Os reduces icache footprint it may even be a net win; people tend to
> benchmark things in tight loops, which favours fast code over small code.

The main effect of -Os compared to -O2 (besides disabling some
reordering of the code and prefetching) is the disabling of various
alignments. I doubt that's a win on all CPUs.

> > - I've already seen a report for an ICE in gcc 2.95 of a user compiling
> >   kernel 2.4 with -Os [1]
> 
> Well there's only one way to find out if we'll hit that.  How's about you
> cook me a patch which switches to -Os unconditionally and we'll see how it
> goes?

I still dislike it, but the patch is below.

cu
Adrian


--- linux-2.6.0-test5-mm4/arch/arm/Makefile.old	2003-09-25 14:38:18.000000000 +0200
+++ linux-2.6.0-test5-mm4/arch/arm/Makefile	2003-09-25 14:40:47.000000000 +0200
@@ -14,8 +14,6 @@
 GZFLAGS		:=-9
 #CFLAGS		+=-pipe
 
-CFLAGS		:=$(CFLAGS:-O2=-Os)
-
 ifeq ($(CONFIG_FRAME_POINTER),y)
 CFLAGS		+=-fno-omit-frame-pointer -mapcs -mno-sched-prolog
 endif
--- linux-2.6.0-test5-mm4/arch/h8300/Makefile.old	2003-09-25 14:38:18.000000000 +0200
+++ linux-2.6.0-test5-mm4/arch/h8300/Makefile	2003-09-25 14:38:24.000000000 +0200
@@ -34,7 +34,7 @@
 ldflags-$(CONFIG_CPU_H8S)	:= -mh8300self
 
 CFLAGS += $(cflags-y)
-CFLAGS += -mint32 -fno-builtin -Os
+CFLAGS += -mint32 -fno-builtin
 CFLAGS += -g
 CFLAGS += -D__linux__
 CFLAGS += -DUTS_SYSNAME=\"uClinux\"
--- linux-2.6.0-test8/Makefile.old	2003-10-18 12:15:51.000000000 +0200
+++ linux-2.6.0-test8/Makefile	2003-10-18 12:16:26.000000000 +0200
@@ -275,7 +275,7 @@
 CPPFLAGS        := -D__KERNEL__ -Iinclude \
 		   $(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include)
 
-CFLAGS 		:= -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \
+CFLAGS 		:= -Wall -Wstrict-prototypes -Wno-trigraphs -Os \
 	  	   -fno-strict-aliasing -fno-common
 AFLAGS		:= -D__ASSEMBLY__
 

Re: [2.6 patch] add a config option for -Os compilation

[Martin J. Bligh]

>> I really doubt it.  Kernel CPU footprint is dominated by dcache misses.  If
>> -Os reduces icache footprint it may even be a net win; people tend to
>> benchmark things in tight loops, which favours fast code over small code.
> 
> The main effect of -Os compared to -O2 (besides disabling some
> reordering of the code and prefetching) is the disabling of various
> alignments. I doubt that's a win on all CPUs.
> 
>> > - I've already seen a report for an ICE in gcc 2.95 of a user compiling
>> >   kernel 2.4 with -Os [1]
>> 
>> Well there's only one way to find out if we'll hit that.  How's about you
>> cook me a patch which switches to -Os unconditionally and we'll see how it
>> goes?
> 
> I still dislike it, but the patch is below.

Please don't - I benchmarked it a while ago, and it's definitely slower.
If you have a puny 128K L2 cache, it might help, but it definitely needs
to be optional.

M.

Re: [2.6 patch] add a config option for -Os compilation

[Andrew Morton]

"Martin J. Bligh" <mbligh@aracnet.com> wrote:
>
> Please don't - I benchmarked it a while ago, and it's definitely slower.

Alan said he generally found -Os to be faster...

Re: [2.6 patch] add a config option for -Os compilation

[Adrian Bunk]

On Sat, Oct 18, 2003 at 10:24:02AM -0700, Andrew Morton wrote:
> "Martin J. Bligh" <mbligh@aracnet.com> wrote:
> >
> > Please don't - I benchmarked it a while ago, and it's definitely slower.
> 
> Alan said he generally found -Os to be faster...

Not exactly:
  http://www.ussg.iu.edu/hypermail/linux/kernel/0211.0/1513.html

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

Re: [2.6 patch] add a config option for -Os compilation

[Andrew Morton]

Adrian Bunk <bunk@fs.tum.de> wrote:
>
> On Sat, Oct 18, 2003 at 10:24:02AM -0700, Andrew Morton wrote:
> > "Martin J. Bligh" <mbligh@aracnet.com> wrote:
> > >
> > > Please don't - I benchmarked it a while ago, and it's definitely slower.
> > 
> > Alan said he generally found -Os to be faster...
> 
> Not exactly:
>   http://www.ussg.iu.edu/hypermail/linux/kernel/0211.0/1513.html
> 

http://www.ussg.iu.edu/hypermail/linux/kernel/0308.1/1261.html

And bear in mind that you can see significant changes in benchmark results
between equivalent kernels even when the optimisation level is kept the
same, due to aliasing and alignment luck.

It would take a quite a lot of work to measure this properly.  A simple A/B
comparison doesn't cut it.

Re: [2.6 patch] add a config option for -Os compilation

[Martin J. Bligh]

>> On Sat, Oct 18, 2003 at 10:24:02AM -0700, Andrew Morton wrote:
>> > "Martin J. Bligh" <mbligh@aracnet.com> wrote:
>> > > 
>> > > Please don't - I benchmarked it a while ago, and it's definitely slower.
>> > 
>> > Alan said he generally found -Os to be faster...
>> 
>> Not exactly:
>>   http://www.ussg.iu.edu/hypermail/linux/kernel/0211.0/1513.html
>> 
> 
> http://www.ussg.iu.edu/hypermail/linux/kernel/0308.1/1261.html
> 
> And bear in mind that you can see significant changes in benchmark results
> between equivalent kernels even when the optimisation level is kept the
> same, due to aliasing and alignment luck.
> 
> It would take a quite a lot of work to measure this properly.  A simple A/B
> comparison doesn't cut it.

So why are we changing it then? ;-) We don't seem to have much evidence
either way. What are the distros doing?

M.

Re: [2.6 patch] add a config option for -Os compilation

[Adrian Bunk]

On Sun, Oct 19, 2003 at 08:43:27AM -0700, Martin J. Bligh wrote:
>...
> So why are we changing it then? ;-) We don't seem to have much evidence
> either way. What are the distros doing?

The exact speed differences need measurements and it might be that
depending on the gcc version and hardware the one or the other is 
faster.

I doubt it would make a noticalble difference in either direction for an
average user who runs Mozilla under KDE. -O2 is IMHO the better default 
since it's well tested through different gcc versions.

The more important point is that -Os code is significantely smaller 
which is important for some applications (e.g. a router-on-a-floppy or 
small embedded systems).

> M.

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

Re: [2.6 patch] add a config option for -Os compilation

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

On Sun, 2003-10-19 at 17:43, Martin J. Bligh wrote:

> So why are we changing it then? ;-) We don't seem to have much evidence
> either way. What are the distros doing?

in the context of boot/rescuefloppies (yes those pesky black things
still exist) I would seriously consider -Os, esp if there's no big
peformance disadvantage....

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.6 patch] add a config option for -Os compilation

[Andrew Morton]

"Martin J. Bligh" <mbligh@aracnet.com> wrote:
>
>  > It would take a quite a lot of work to measure this properly.  A simple A/B
>  > comparison doesn't cut it.
> 
>  So why are we changing it then? ;-)

It is very easy to demonstrate that it saves 300 kilobytes of memory.

Re: [2.6 patch] add a config option for -Os compilation

[Martin J. Bligh]

> "Martin J. Bligh" <mbligh@aracnet.com> wrote:
>> 
>>  > It would take a quite a lot of work to measure this properly.  A simple A/B
>>  > comparison doesn't cut it.
>> 
>>  So why are we changing it then? ;-)
> 
> It is very easy to demonstrate that it saves 300 kilobytes of memory.

OK, fair enough - so can we either do:

1) a config option

or 

2) if you hate that, at least switch it to -O2 on CONFIG_SMP, on the grounds
that such systems generally have larger caches, and plenty of RAM.

M.

Re: [2.6 patch] add a config option for -Os compilation

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

On Sat, 2003-10-18 12:21:27 +0200, Adrian Bunk <bunk@fs.tum.de>
wrote in message <20031018102127.GE12423@fs.tum.de>:
> On Wed, Oct 15, 2003 at 04:52:05PM -0700, Andrew Morton wrote:
> > I really doubt it.  Kernel CPU footprint is dominated by dcache misses.  If
> > -Os reduces icache footprint it may even be a net win; people tend to
> > benchmark things in tight loops, which favours fast code over small code.
> 
> The main effect of -Os compared to -O2 (besides disabling some
> reordering of the code and prefetching) is the disabling of various
> alignments. I doubt that's a win on all CPUs.

I definively *like* to see -Os be configureable by user. It's *big* win
for a lowmem system. There, the actual "running speed" may be limited by
HDD swap speed, and having a smaller kernel means having more pages left
to luserspace...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[2.6 patch] add a config option for -Os compilation

[Adrian Bunk]

The patch below adds a config option OPTIMIZE_FOR_SIZE for telling gcc 
to use -Os instead of -O2. Besides this, it removes constructs on 
architectures that had a -Os hardcoded in their Makefiles.

It works for me, I'm currently running a 2.6.0-test5 compild with this 
option enabled and there are no obvious problems.

The last time I sent this to linux-kernel there were one positive and 
zero negative reactions.

diffstat output:

 Makefile            |    8 +++++++-
 arch/arm/Makefile   |    2 --
 arch/h8300/Makefile |    2 +-
 init/Kconfig        |    9 +++++++++
 4 files changed, 17 insertions(+), 4 deletions(-)

Please apply
Adrian

--- linux-2.6.0-test5-Os/init/Kconfig.old	2003-09-13 17:30:50.000000000 +0200
+++ linux-2.6.0-test5-Os/init/Kconfig	2003-09-13 17:30:59.000000000 +0200
@@ -65,6 +65,15 @@
 
 menu "General setup"
 
+config OPTIMIZE_FOR_SIZE
+	bool "Optimize for size" if EXPERIMENTAL
+	default n
+	help
+	  Enabling this option will pass "-Os" instead of "-O2" to gcc
+	  resulting in a smaller kernel.
+
+	  If unsure, say N.
+
 config SWAP
 	bool "Support for paging of anonymous memory"
 	depends on MMU
--- linux-2.6.0-test5-Os/Makefile.old	2003-09-13 17:30:50.000000000 +0200
+++ linux-2.6.0-test5-Os/Makefile	2003-09-13 17:30:59.000000000 +0200
@@ -223,7 +223,7 @@
 NOSTDINC_FLAGS  = -nostdinc -iwithprefix include
 
 CPPFLAGS	:= -D__KERNEL__ -Iinclude
-CFLAGS 		:= -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \
+CFLAGS 		:= -Wall -Wstrict-prototypes -Wno-trigraphs \
 	  	   -fno-strict-aliasing -fno-common
 AFLAGS		:= -D__ASSEMBLY__
 
@@ -370,6 +370,12 @@
 # ---------------------------------------------------------------------------
 
 
+ifdef CONFIG_OPTIMIZE_FOR_SIZE
+CFLAGS		+= -Os
+else
+CFLAGS		+= -O2
+endif
+
 ifndef CONFIG_FRAME_POINTER
 CFLAGS		+= -fomit-frame-pointer
 endif
--- linux-2.6.0-test5-Os/arch/arm/Makefile.old	2003-09-13 17:30:50.000000000 +0200
+++ linux-2.6.0-test5-Os/arch/arm/Makefile	2003-09-13 17:30:59.000000000 +0200
@@ -14,8 +14,6 @@
 GZFLAGS		:=-9
 #CFLAGS		+=-pipe
 
-CFLAGS		:=$(CFLAGS:-O2=-Os)
-
 ifeq ($(CONFIG_FRAME_POINTER),y)
 CFLAGS		+=-fno-omit-frame-pointer -mapcs -mno-sched-prolog
 endif
--- linux-2.6.0-test5-Os/arch/h8300/Makefile.old	2003-09-13 17:30:50.000000000 +0200
+++ linux-2.6.0-test5-Os/arch/h8300/Makefile	2003-09-13 17:30:59.000000000 +0200
@@ -34,7 +34,7 @@
 ldflags-$(CONFIG_CPU_H8S)	:= -mh8300self
 
 CFLAGS += $(cflags-y)
-CFLAGS += -mint32 -fno-builtin -Os
+CFLAGS += -mint32 -fno-builtin
 CFLAGS += -g
 CFLAGS += -D__linux__
 CFLAGS += -DUTS_SYSNAME=\"uClinux\"

Re: [2.6 patch] add a config option for -Os compilation

[Russell King]

On Sun, Sep 14, 2003 at 02:16:56PM +0200, Adrian Bunk wrote:
> The patch below adds a config option OPTIMIZE_FOR_SIZE for telling gcc 
> to use -Os instead of -O2. Besides this, it removes constructs on 
> architectures that had a -Os hardcoded in their Makefiles.

I'd rather retain the -Os default for ARM please.  (The init/Kconfig
defaults it to 'n' for everything.)

-- 
Russell King (rmk@arm.linux.org.uk)	http://www.arm.linux.org.uk/personal/
Linux kernel maintainer of:
  2.6 ARM Linux   - http://www.arm.linux.org.uk/
  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
  2.6 Serial core

Re: [2.6 patch] add a config option for -Os compilation

[Adrian Bunk]

On Sun, Sep 14, 2003 at 01:33:49PM +0100, Russell King wrote:
> On Sun, Sep 14, 2003 at 02:16:56PM +0200, Adrian Bunk wrote:
> > The patch below adds a config option OPTIMIZE_FOR_SIZE for telling gcc 
> > to use -Os instead of -O2. Besides this, it removes constructs on 
> > architectures that had a -Os hardcoded in their Makefiles.
> 
> I'd rather retain the -Os default for ARM please.  (The init/Kconfig
> defaults it to 'n' for everything.)

Below is the patch with the ARM part omitted.

cu
Adrian

--- linux-2.6.0-test5-Os/init/Kconfig.old	2003-09-13 17:30:50.000000000 +0200
+++ linux-2.6.0-test5-Os/init/Kconfig	2003-09-13 17:30:59.000000000 +0200
@@ -65,6 +65,15 @@
 
 menu "General setup"
 
+config OPTIMIZE_FOR_SIZE
+	bool "Optimize for size" if EXPERIMENTAL
+	default n
+	help
+	  Enabling this option will pass "-Os" instead of "-O2" to gcc
+	  resulting in a smaller kernel.
+
+	  If unsure, say N.
+
 config SWAP
 	bool "Support for paging of anonymous memory"
 	depends on MMU
--- linux-2.6.0-test5-Os/Makefile.old	2003-09-13 17:30:50.000000000 +0200
+++ linux-2.6.0-test5-Os/Makefile	2003-09-13 17:30:59.000000000 +0200
@@ -223,7 +223,7 @@
 NOSTDINC_FLAGS  = -nostdinc -iwithprefix include
 
 CPPFLAGS	:= -D__KERNEL__ -Iinclude
-CFLAGS 		:= -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \
+CFLAGS 		:= -Wall -Wstrict-prototypes -Wno-trigraphs \
 	  	   -fno-strict-aliasing -fno-common
 AFLAGS		:= -D__ASSEMBLY__
 
@@ -370,6 +370,12 @@
 # ---------------------------------------------------------------------------
 
 
+ifdef CONFIG_OPTIMIZE_FOR_SIZE
+CFLAGS		+= -Os
+else
+CFLAGS		+= -O2
+endif
+
 ifndef CONFIG_FRAME_POINTER
 CFLAGS		+= -fomit-frame-pointer
 endif
--- linux-2.6.0-test5-Os/arch/h8300/Makefile.old	2003-09-13 17:30:50.000000000 +0200
+++ linux-2.6.0-test5-Os/arch/h8300/Makefile	2003-09-13 17:30:59.000000000 +0200
@@ -34,7 +34,7 @@
 ldflags-$(CONFIG_CPU_H8S)	:= -mh8300self
 
 CFLAGS += $(cflags-y)
-CFLAGS += -mint32 -fno-builtin -Os
+CFLAGS += -mint32 -fno-builtin
 CFLAGS += -g
 CFLAGS += -D__linux__
 CFLAGS += -DUTS_SYSNAME=\"uClinux\"

Re: [2.6 patch] add a config option for -Os compilation

[Russell King]

On Sun, Sep 14, 2003 at 03:21:43PM +0200, Adrian Bunk wrote:
> On Sun, Sep 14, 2003 at 01:33:49PM +0100, Russell King wrote:
> > On Sun, Sep 14, 2003 at 02:16:56PM +0200, Adrian Bunk wrote:
> > > The patch below adds a config option OPTIMIZE_FOR_SIZE for telling gcc 
> > > to use -Os instead of -O2. Besides this, it removes constructs on 
> > > architectures that had a -Os hardcoded in their Makefiles.
> > 
> > I'd rather retain the -Os default for ARM please.  (The init/Kconfig
> > defaults it to 'n' for everything.)
> 
> Below is the patch with the ARM part omitted.

But it doesn't make sense - you include a generic configuration option
which people will see, yet it makes no effect on ARM - seems to be rather
silly putting it there in the first place.

Also, do users particularly care what -Os and -O2 mean?

Maybe you need to change init/Kconfig to be something like the following,
and reinstate the change to the ARM makefile:

config OPTIMIZE_FOR_SIZE
	bool "Optimize for size" if EXPERIMENTAL
	default n if !ARM
	default y if ARM
	help
	  Enabling this option will cause the compiler to reduce the code
	  size of the kernel by disabling certain optimisations.  However,
	  the resulting kernel may run faster due to more efficient
	  cache utilisation.

	  If unsure, say N.

-- 
Russell King (rmk@arm.linux.org.uk)	http://www.arm.linux.org.uk/personal/
Linux kernel maintainer of:
  2.6 ARM Linux   - http://www.arm.linux.org.uk/
  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
  2.6 Serial core

Re: [2.6 patch] add a config option for -Os compilation

[Adrian Bunk]

On Sun, Sep 14, 2003 at 03:52:45PM +0100, Russell King wrote:
> 
> But it doesn't make sense - you include a generic configuration option
> which people will see, yet it makes no effect on ARM - seems to be rather
> silly putting it there in the first place.
> 
> Also, do users particularly care what -Os and -O2 mean?

The "If unsure, say N." should take care of it. People who really need 
small kernels usually know what -Os means.

> Maybe you need to change init/Kconfig to be something like the following,
> and reinstate the change to the ARM makefile:
> 
> config OPTIMIZE_FOR_SIZE
> 	bool "Optimize for size" if EXPERIMENTAL
> 	default n if !ARM
> 	default y if ARM

That's a good idea.

The patch below does this for ARM and H8300.
Since there was no H8300 symbol, I added it to arch/h8300/Kconfig 
similar to the symbols on other architectures.

> 	help
> 	  Enabling this option will cause the compiler to reduce the code
> 	  size of the kernel by disabling certain optimisations.  However,
> 	  the resulting kernel may run faster due to more efficient
> 	  cache utilisation.
>...

I don't like this part, it would cause confusion. -O2 is more widely
tested, and though if there might be small improvements on some CPUs
with some compiler versions, it's untested whether -Os might cause worse
performance of some fast path code in any area of the kernel.
OPTIMIZE_FOR_SIZE should, although of low risk, be an "only use it if
you know what you are doing" option.


diffstat output for the patch below:

 Makefile            |    8 +++++++-
 arch/arm/Makefile   |    2 --
 arch/h8300/Kconfig  |    4 ++++
 arch/h8300/Makefile |    2 +-
 init/Kconfig        |   10 ++++++++++
 5 files changed, 22 insertions(+), 4 deletions(-)


cu
Adrian

--- linux-2.6.0-test5-mm4/init/Kconfig.old	2003-09-25 14:38:18.000000000 +0200
+++ linux-2.6.0-test5-mm4/init/Kconfig	2003-09-25 14:47:12.000000000 +0200
@@ -65,6 +65,16 @@
 
 menu "General setup"
 
+config OPTIMIZE_FOR_SIZE
+	bool "Optimize for size" if EXPERIMENTAL
+	default y if ARM || H8300
+	default n
+	help
+	  Enabling this option will pass "-Os" instead of "-O2" to gcc
+	  resulting in a smaller kernel.
+
+	  If unsure, say N.
+
 config SWAP
 	bool "Support for paging of anonymous memory"
 	depends on MMU
--- linux-2.6.0-test5-mm4/Makefile.old	2003-09-25 14:38:18.000000000 +0200
+++ linux-2.6.0-test5-mm4/Makefile	2003-09-25 14:40:26.000000000 +0200
@@ -274,7 +274,7 @@
 CPPFLAGS        := -D__KERNEL__ -Iinclude \
 		   $(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include)
 
-CFLAGS 		:= -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \
+CFLAGS 		:= -Wall -Wstrict-prototypes -Wno-trigraphs \
 	  	   -fno-strict-aliasing -fno-common
 AFLAGS		:= -D__ASSEMBLY__
 
@@ -421,6 +421,12 @@
 # ---------------------------------------------------------------------------
 
 
+ifdef CONFIG_OPTIMIZE_FOR_SIZE
+CFLAGS		+= -Os
+else
+CFLAGS		+= -O2
+endif
+
 ifndef CONFIG_FRAME_POINTER
 CFLAGS		+= -fomit-frame-pointer
 endif
--- linux-2.6.0-test5-mm4/arch/arm/Makefile.old	2003-09-25 14:38:18.000000000 +0200
+++ linux-2.6.0-test5-mm4/arch/arm/Makefile	2003-09-25 14:40:47.000000000 +0200
@@ -14,8 +14,6 @@
 GZFLAGS		:=-9
 #CFLAGS		+=-pipe
 
-CFLAGS		:=$(CFLAGS:-O2=-Os)
-
 ifeq ($(CONFIG_FRAME_POINTER),y)
 CFLAGS		+=-fno-omit-frame-pointer -mapcs -mno-sched-prolog
 endif
--- linux-2.6.0-test5-mm4/arch/h8300/Kconfig.old	2003-09-25 14:43:27.000000000 +0200
+++ linux-2.6.0-test5-mm4/arch/h8300/Kconfig	2003-09-25 14:43:44.000000000 +0200
@@ -5,6 +5,10 @@
 
 mainmenu "uClinux/h8300 (w/o MMU) Kernel Configuration"
 
+config H8300
+	bool
+	default y
+
 config MMU
 	bool
 	default n
--- linux-2.6.0-test5-mm4/arch/h8300/Makefile.old	2003-09-25 14:38:18.000000000 +0200
+++ linux-2.6.0-test5-mm4/arch/h8300/Makefile	2003-09-25 14:38:24.000000000 +0200
@@ -34,7 +34,7 @@
 ldflags-$(CONFIG_CPU_H8S)	:= -mh8300self
 
 CFLAGS += $(cflags-y)
-CFLAGS += -mint32 -fno-builtin -Os
+CFLAGS += -mint32 -fno-builtin
 CFLAGS += -g
 CFLAGS += -D__linux__
 CFLAGS += -DUTS_SYSNAME=\"uClinux\"

Re: [2.6 patch] add a config option for -Os compilation

[Sam Ravnborg]

On Thu, Sep 25, 2003 at 04:38:45PM +0200, Adrian Bunk wrote:
> --- linux-2.6.0-test5-mm4/init/Kconfig.old	2003-09-25 14:38:18.000000000 +0200
> +++ linux-2.6.0-test5-mm4/init/Kconfig	2003-09-25 14:47:12.000000000 +0200
> @@ -65,6 +65,16 @@
>  
>  menu "General setup"
>  
> +config OPTIMIZE_FOR_SIZE
> +	bool "Optimize for size" if EXPERIMENTAL
> +	default y if ARM || H8300
> +	default n
> +	help
> +	  Enabling this option will pass "-Os" instead of "-O2" to gcc
> +	  resulting in a smaller kernel.
> +
> +	  If unsure, say N.
> +

This is a general file, and it is wrong to include architecture specific
knowledge here.
I recall that Roman Zippel introduced "enable" for exactly this purpose.

I looked into Documentation/kbuild/kconfig-language.txt but did not
see it documented - Roman?

Another comment about the naming of the config symbol.
We keep getting more config symbols controlling options to GCC.
A naming scheme like: CONFIG_CC_OPTIMIZE_FOR_SIZE, CONFIG_CC_DEBUG_INFO
is preferable since it give better context information.
Let's start with this option, and rename the others later.

	Sam

Re: [2.6 patch] add a config option for -Os compilation

[Russell King]

On Thu, Sep 25, 2003 at 08:11:27PM +0200, Sam Ravnborg wrote:
> On Thu, Sep 25, 2003 at 04:38:45PM +0200, Adrian Bunk wrote:
> > --- linux-2.6.0-test5-mm4/init/Kconfig.old	2003-09-25 14:38:18.000000000 +0200
> > +++ linux-2.6.0-test5-mm4/init/Kconfig	2003-09-25 14:47:12.000000000 +0200
> > @@ -65,6 +65,16 @@
> >  
> >  menu "General setup"
> >  
> > +config OPTIMIZE_FOR_SIZE
> > +	bool "Optimize for size" if EXPERIMENTAL
> > +	default y if ARM || H8300
> > +	default n
> > +	help
> > +	  Enabling this option will pass "-Os" instead of "-O2" to gcc
> > +	  resulting in a smaller kernel.
> > +
> > +	  If unsure, say N.
> > +
> 
> This is a general file, and it is wrong to include architecture specific
> knowledge here.

In which case we need to replicate the option in each of the per-
architecture files.  That seems a bit wasteful though.

I don't think "select" will hack it in this case though.

-- 
Russell King (rmk@arm.linux.org.uk)	http://www.arm.linux.org.uk/personal/
      Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
      maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                      2.6 Serial core

Re: [2.6 patch] add a config option for -Os compilation

[Adrian Bunk]

On Thu, Sep 25, 2003 at 08:11:27PM +0200, Sam Ravnborg wrote:
> On Thu, Sep 25, 2003 at 04:38:45PM +0200, Adrian Bunk wrote:
> > --- linux-2.6.0-test5-mm4/init/Kconfig.old	2003-09-25 14:38:18.000000000 +0200
> > +++ linux-2.6.0-test5-mm4/init/Kconfig	2003-09-25 14:47:12.000000000 +0200
> > @@ -65,6 +65,16 @@
> >  
> >  menu "General setup"
> >  
> > +config OPTIMIZE_FOR_SIZE
> > +	bool "Optimize for size" if EXPERIMENTAL
> > +	default y if ARM || H8300
> > +	default n
> > +	help
> > +	  Enabling this option will pass "-Os" instead of "-O2" to gcc
> > +	  resulting in a smaller kernel.
> > +
> > +	  If unsure, say N.
> > +
> 
> This is a general file, and it is wrong to include architecture specific
> knowledge here.
> I recall that Roman Zippel introduced "enable" for exactly this purpose.
>...

I can't see how this would help in this situation, we need a default, 
not a dependency (OPTIMIZE_FOR_SIZE=n should be possible on ARM).

It's not the only option that sets defaults depending on the 
architecture and I can't see why it should be a bad thing.

> Another comment about the naming of the config symbol.
> We keep getting more config symbols controlling options to GCC.
> A naming scheme like: CONFIG_CC_OPTIMIZE_FOR_SIZE, CONFIG_CC_DEBUG_INFO
> is preferable since it give better context information.
> Let's start with this option, and rename the others later.

Below is the patch with CONFIG_CC_OPTIMIZE_FOR_SIZE.

> 	Sam

cu
Adrian

--- linux-2.6.0-test5-mm4/init/Kconfig.old	2003-09-25 14:38:18.000000000 +0200
+++ linux-2.6.0-test5-mm4/init/Kconfig	2003-09-25 14:47:12.000000000 +0200
@@ -65,6 +65,16 @@
 
 menu "General setup"
 
+config CC_OPTIMIZE_FOR_SIZE
+	bool "Optimize for size" if EXPERIMENTAL
+	default y if ARM || H8300
+	default n
+	help
+	  Enabling this option will pass "-Os" instead of "-O2" to gcc
+	  resulting in a smaller kernel.
+
+	  If unsure, say N.
+
 config SWAP
 	bool "Support for paging of anonymous memory"
 	depends on MMU
--- linux-2.6.0-test5-mm4/Makefile.old	2003-09-25 14:38:18.000000000 +0200
+++ linux-2.6.0-test5-mm4/Makefile	2003-09-25 14:40:26.000000000 +0200
@@ -274,7 +274,7 @@
 CPPFLAGS        := -D__KERNEL__ -Iinclude \
 		   $(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include)
 
-CFLAGS 		:= -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \
+CFLAGS 		:= -Wall -Wstrict-prototypes -Wno-trigraphs \
 	  	   -fno-strict-aliasing -fno-common
 AFLAGS		:= -D__ASSEMBLY__
 
@@ -421,6 +421,12 @@
 # ---------------------------------------------------------------------------
 
 
+ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
+CFLAGS		+= -Os
+else
+CFLAGS		+= -O2
+endif
+
 ifndef CONFIG_FRAME_POINTER
 CFLAGS		+= -fomit-frame-pointer
 endif
--- linux-2.6.0-test5-mm4/arch/arm/Makefile.old	2003-09-25 14:38:18.000000000 +0200
+++ linux-2.6.0-test5-mm4/arch/arm/Makefile	2003-09-25 14:40:47.000000000 +0200
@@ -14,8 +14,6 @@
 GZFLAGS		:=-9
 #CFLAGS		+=-pipe
 
-CFLAGS		:=$(CFLAGS:-O2=-Os)
-
 ifeq ($(CONFIG_FRAME_POINTER),y)
 CFLAGS		+=-fno-omit-frame-pointer -mapcs -mno-sched-prolog
 endif
--- linux-2.6.0-test5-mm4/arch/h8300/Kconfig.old	2003-09-25 14:43:27.000000000 +0200
+++ linux-2.6.0-test5-mm4/arch/h8300/Kconfig	2003-09-25 14:43:44.000000000 +0200
@@ -5,6 +5,10 @@
 
 mainmenu "uClinux/h8300 (w/o MMU) Kernel Configuration"
 
+config H8300
+	bool
+	default y
+
 config MMU
 	bool
 	default n
--- linux-2.6.0-test5-mm4/arch/h8300/Makefile.old	2003-09-25 14:38:18.000000000 +0200
+++ linux-2.6.0-test5-mm4/arch/h8300/Makefile	2003-09-25 14:38:24.000000000 +0200
@@ -34,7 +34,7 @@
 ldflags-$(CONFIG_CPU_H8S)	:= -mh8300self
 
 CFLAGS += $(cflags-y)
-CFLAGS += -mint32 -fno-builtin -Os
+CFLAGS += -mint32 -fno-builtin
 CFLAGS += -g
 CFLAGS += -D__linux__
 CFLAGS += -DUTS_SYSNAME=\"uClinux\"

Re: [2.6 patch] add a config option for -Os compilation

[Wade]

Adrian Bunk wrote:
> The patch below adds a config option OPTIMIZE_FOR_SIZE for telling gcc 
> to use -Os instead of -O2. Besides this, it removes constructs on 
> architectures that had a -Os hardcoded in their Makefiles.

Someone told me that -Os is actually faster than -O2 for Athlons, is 
that true?

Re: [2.6 patch] add a config option for -Os compilation

[Alan Cox]

On Sul, 2003-09-14 at 14:53, Wade wrote:
> Adrian Bunk wrote:
> > The patch below adds a config option OPTIMIZE_FOR_SIZE for telling gcc 
> > to use -Os instead of -O2. Besides this, it removes constructs on 
> > architectures that had a -Os hardcoded in their Makefiles.
> 
> Someone told me that -Os is actually faster than -O2 for Athlons, is 
> that true?

On gcc 2.95 -Os was faster for most stuff. I would intuitively expect
the best result to be a mix varied by function but I don't think gcc has
the support to do that.

I've also not benched gcc 3.2 -Os v -O2 at real workloads - thats a 
nice little project for someone.

Re: [2.6 patch] add a config option for -Os compilation

[Martin J. Bligh]

--Alan Cox <alan@lxorguk.ukuu.org.uk> wrote (on Sunday, September 14, 2003 15:57:49 +0100):

> On Sul, 2003-09-14 at 14:53, Wade wrote:
>> Adrian Bunk wrote:
>> > The patch below adds a config option OPTIMIZE_FOR_SIZE for telling gcc 
>> > to use -Os instead of -O2. Besides this, it removes constructs on 
>> > architectures that had a -Os hardcoded in their Makefiles.
>> 
>> Someone told me that -Os is actually faster than -O2 for Athlons, is 
>> that true?
> 
> On gcc 2.95 -Os was faster for most stuff. I would intuitively expect
> the best result to be a mix varied by function but I don't think gcc has
> the support to do that.
> 
> I've also not benched gcc 3.2 -Os v -O2 at real workloads - thats a 
> nice little project for someone.

I think it depends heavily on the chip - I tried 2.95 and 3.3. For me,
-Os was slower for both, but I have a 2MB L2 cache. If you have a 128K
celeron or something, I'm sure it'd be faster.

M.