-O more than the sum of its parts?

-O more than the sum of its parts?

[drew stortz]

From the following page

http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Optimize-Options.html#Optimize-Options

I gather that using GCC 4.2.2 with the -O option is the equivalent of
using all of the following options explicitly: -fdefer-pop
-fdelayed-branch -fguess-branch-probability -fcprop-registers
-fif-conversion -fif-conversion2 -ftree-ccp -ftree-dce
-ftree-dominator-opts -ftree-dse -ftree-ter -ftree-lrs -ftree-sra
-ftree-copyrename -ftree-fre -ftree-ch -funit-at-a-time
-fmerge-constants -fomit-frame-pointer

However, experiment tells me that this is far from true.  When I
compile the same c file both ways, the object file produced with -O is
around 20% smaller than the one produced with all of the individual
optimizations added.  Before filing a bug or investigating further, I
wanted to ask the list: is my interpretation of the -O switch
incorrect?  Is it more than just the sum of those individual
optimizations?

I’m using sles9 sp3 on an x86-64 machine, and the observation hold
whether using -m32 or -m64 and also whether I include or exclude
-fomit-frame-pointer

thanks for your help,
Drew

Re: -O more than the sum of its parts?

[me22]

On 8 March 2010 22:31, drew stortz <drew.stortz@gmail.com> wrote:
>
> However, experiment tells me that this is far from true.  When I
> compile the same c file both ways, the object file produced with -O is
> around 20% smaller than the one produced with all of the individual
> optimizations added.  Before filing a bug or investigating further, I
> wanted to ask the list: is my interpretation of the -O switch
> incorrect?  Is it more than just the sum of those individual
> optimizations?
>

Yes; My understanding is that all of the -O levels have features not
controllable with individual flags.

Re: -O more than the sum of its parts?

[Diego Novillo]

On Mon, Mar 8, 2010 at 22:43, me22 <me22.ca@gmail.com> wrote:

> Yes; My understanding is that all of the -O levels have features not
> controllable with individual flags.

Correct.  You can see for yourself by grepping for uses of the
variable 'optimize' in the GCC source code.  Many code paths are
affected by it.


Diego.

Re: -O more than the sum of its parts?

[Alexey Salmin]

On Tue, Mar 9, 2010 at 9:31 AM, drew stortz <drew.stortz@gmail.com> wrote:
> From the following page
>
> http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Optimize-Options.html#Optimize-Options
>
> I gather that using GCC 4.2.2 with the -O option is the equivalent of
> using all of the following options explicitly: -fdefer-pop
> -fdelayed-branch -fguess-branch-probability -fcprop-registers
> -fif-conversion -fif-conversion2 -ftree-ccp -ftree-dce
> -ftree-dominator-opts -ftree-dse -ftree-ter -ftree-lrs -ftree-sra
> -ftree-copyrename -ftree-fre -ftree-ch -funit-at-a-time
> -fmerge-constants -fomit-frame-pointer
>
> However, experiment tells me that this is far from true.  When I
> compile the same c file both ways, the object file produced with -O is
> around 20% smaller than the one produced with all of the individual
> optimizations added.  Before filing a bug or investigating further, I
> wanted to ask the list: is my interpretation of the -O switch
> incorrect?  Is it more than just the sum of those individual
> optimizations?
>
> I’m using sles9 sp3 on an x86-64 machine, and the observation hold
> whether using -m32 or -m64 and also whether I include or exclude
> -fomit-frame-pointer
>
> thanks for your help,
> Drew
>

http://gcc.gnu.org/ml/gcc-help/2009-10/msg00128.html

Re: -O more than the sum of its parts?

[NightStrike]

On Mon, Mar 8, 2010 at 11:09 PM, Alexey Salmin <alexey.salmin@gmail.com> wrote:
>> optimizations added.  Before filing a bug or investigating further, I
>> wanted to ask the list: is my interpretation of the -O switch
>> incorrect?  Is it more than just the sum of those individual
>> optimizations?
>
> http://gcc.gnu.org/ml/gcc-help/2009-10/msg00128.html
>

Also, the post with the full explanation is here, further down in the thread:
http://gcc.gnu.org/ml/gcc-help/2009-10/msg00134.html