optimization issue about -O2 and -Os

optimization issue about -O2 and -Os

[Ebony Zhu]

Hi, Everybody,

I'm new to this mailing list. I encountered an odd issue about gcc
optimization. I'm using a cross-built gcc 3.3.2 for Powerpc. When I
build some applications such as U-Boot, Busybox..., with the -Os
optimization, the apps can be built but cannot run (just halted, there
were even no error messages). If I use -O2 switch then everything is OK.

According to manpage of GCC, -Os is based on -O2 switch and does some
work to reduce the code size. What GCC did on earth with the -Os switch?

Anybody has some idea about this odd issue? Many thanks!

B.R.
EBony

Re: optimization issue about -O2 and -Os

[Jim Wilson]

Ebony Zhu wrote:
> build some applications such as U-Boot, Busybox..., with the -Os
> optimization, the apps can be built but cannot run (just halted, there
> were even no error messages). If I use -O2 switch then everything is OK.
> 
> According to manpage of GCC, -Os is based on -O2 switch and does some
> work to reduce the code size. What GCC did on earth with the -Os switch?

The -Os option is buggy.  You might want to report a bug into our 
bugzilla bug datase.  See
     http://gcc.gnu.org/bugs.html
for more info on reporting bugs.

Though the -Os option is based on the -O2 option, it is a different 
option, that generates different code, and has different bugs.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: optimization issue about -O2 and -Os

[Ebony Zhu]

Have you ever been troubled in the same problem? Are you sure it's a gcc
bug, and not a mistake I probably made when building the cross tool?
(e.g. missed some important options when building gcc).

B.R
Ebony

On Fri, 2004-04-30 at 06:58, Jim Wilson wrote:
> Ebony Zhu wrote:
> > build some applications such as U-Boot, Busybox..., with the -Os
> > optimization, the apps can be built but cannot run (just halted, there
> > were even no error messages). If I use -O2 switch then everything is OK.
> > 
> > According to manpage of GCC, -Os is based on -O2 switch and does some
> > work to reduce the code size. What GCC did on earth with the -Os switch?
> 
> The -Os option is buggy.  You might want to report a bug into our 
> bugzilla bug datase.  See
>      http://gcc.gnu.org/bugs.html
> for more info on reporting bugs.
> 
> Though the -Os option is based on the -O2 option, it is a different 
> option, that generates different code, and has different bugs.
> -- 
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: optimization issue about -O2 and -Os

[Jim Wilson]

On Thu, 2004-04-29 at 19:34, Ebony Zhu wrote:
> Have you ever been troubled in the same problem? Are you sure it's a gcc
> bug, and not a mistake I probably made when building the cross tool?
> (e.g. missed some important options when building gcc).

If something compiled with -O2 works and something compiled with -Os
does not work, then the logical conclusion is that the -Os option is
buggy.

However, it is possible that something went wrong with your build, if
you are trying to do something complicated.  Since you didn't say
anything about how you built the toolchain, or what you built, I can't
comment on this.  I was just assuming that you had one toolchain, and
the only thing that changed was the -O2/-Os option when using it.

I deal with gcc bugs everyday, but I don't have any specific knowledge
about -Os PPC gcc-3.3.2 bugs.

You might try debugging the problem a bit to see what is wrong.  Run the
programs under gdb and see where they fail.  Put a breakpoint in main to
see if maybe they fail before main is reached.  Etc.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: optimization issue about -O2 and -Os

[Ebony Zhu]

Thank you for your help, maybe I need to debug the applications with
gdb.

B.R
Ebony
 
On Fri, 2004-04-30 at 12:05, Jim Wilson wrote:
> On Thu, 2004-04-29 at 19:34, Ebony Zhu wrote:
> > Have you ever been troubled in the same problem? Are you sure it's a gcc
> > bug, and not a mistake I probably made when building the cross tool?
> > (e.g. missed some important options when building gcc).
> 
> If something compiled with -O2 works and something compiled with -Os
> does not work, then the logical conclusion is that the -Os option is
> buggy.
> 
> However, it is possible that something went wrong with your build, if
> you are trying to do something complicated.  Since you didn't say
> anything about how you built the toolchain, or what you built, I can't
> comment on this.  I was just assuming that you had one toolchain, and
> the only thing that changed was the -O2/-Os option when using it.
> 
> I deal with gcc bugs everyday, but I don't have any specific knowledge
> about -Os PPC gcc-3.3.2 bugs.
> 
> You might try debugging the problem a bit to see what is wrong.  Run the
> programs under gdb and see where they fail.  Put a breakpoint in main to
> see if maybe they fail before main is reached.  Etc.
> -- 
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

RE: optimization issue about -O2 and -Os

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Jim Wilson
> Sent: 30 April 2004 05:06

> On Thu, 2004-04-29 at 19:34, Ebony Zhu wrote:
> > Have you ever been troubled in the same problem? Are you 
> sure it's a gcc
> > bug, and not a mistake I probably made when building the cross tool?
> > (e.g. missed some important options when building gcc).
> 
> If something compiled with -O2 works and something compiled with -Os
> does not work, then the logical conclusion is that the -Os option is
> buggy.
> 
> However, it is possible that something went wrong with your build, if
> you are trying to do something complicated.  Since you didn't say
> anything about how you built the toolchain, or what you built, I can't
> comment on this.  I was just assuming that you had one toolchain, and
> the only thing that changed was the -O2/-Os option when using it.
> 
> I deal with gcc bugs everyday, but I don't have any specific knowledge
> about -Os PPC gcc-3.3.2 bugs.
> 
> You might try debugging the problem a bit to see what is 
> wrong.  Run the
> programs under gdb and see where they fail.  Put a breakpoint 
> in main to
> see if maybe they fail before main is reached.  Etc.

  Use -fverbose-asm in conjunction with --save-temps to get a list of the
optimisations in effect at the top of each assembler code file.  Try it with
-Os and -O2, and note the differences between them.  You may be able to
narrow it down to a specific -f flag by starting with -O2 and introducing
the changes between that and -Os one at a time. 


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: optimization issue about -O2 and -Os

[Zack Weinberg]

"Dave Korn" <dk@artimi.com> writes:

>   Use -fverbose-asm in conjunction with --save-temps to get a list of the
> optimisations in effect at the top of each assembler code file.  Try it with
> -Os and -O2, and note the differences between them.  You may be able to
> narrow it down to a specific -f flag by starting with -O2 and introducing
> the changes between that and -Os one at a time. 

There are no such flags.  The -O options are *not* shorthand for
collections of -f options; I know the documentation makes it sound
that way.  -Os in particular has direct and complex effects on code
generation.

zw

RE: optimization issue about -O2 and -Os

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Zack Weinberg
> Sent: 30 April 2004 16:32

> "Dave Korn" <dk@artimi.com> writes:
> 
> >   Use -fverbose-asm in conjunction with --save-temps to get 
> a list of the
> > optimisations in effect at the top of each assembler code 
> file.  Try it with
> > -Os and -O2, and note the differences between them.  You 
> may be able to
> > narrow it down to a specific -f flag by starting with -O2 
> and introducing
> > the changes between that and -Os one at a time. 
> 
> There are no such flags.  The -O options are *not* shorthand for
> collections of -f options; I know the documentation makes it sound
> that way.  -Os in particular has direct and complex effects on code
> generation.
> 
> zw


  Ah, I stand corrected.  Would it be accurate to say that they are _both_
shorthand for a set of -f options _and_ _also_ control a set of other
behaviours, which entail enabling, disabling, or fine-tuning the parameters
of other optimisations that do not correspond directly to -f options ?

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: optimization issue about -O2 and -Os

[Zack Weinberg]

"Dave Korn" <dk@artimi.com> writes:

>
>   Ah, I stand corrected.  Would it be accurate to say that they are _both_
> shorthand for a set of -f options _and_ _also_ control a set of other
> behaviours, which entail enabling, disabling, or fine-tuning the parameters
> of other optimisations that do not correspond directly to -f options ?

Yeah, that's pretty accurate.  You can look through the source code
for instances of the global flags "optimize" and "optimize_size".
Anything you can do to improve the documentation in this regard would
be much appreciated.  It would probably be a good move to deemphasize
all those -f switches; they tend not to be all that useful; I consider
their primary purpose to be working around bugs in specific
optimizations, using -On -fno-<buggy-pass>.

zw

RE: optimization issue about -O2 and -Os

[Dave Korn]

> -----Original Message-----
> From: Zack Weinberg 
> Sent: 30 April 2004 18:00

> "Dave Korn" <> writes:
> 
> >
> >   Ah, I stand corrected.  Would it be accurate to say that 
> they are _both_
> > shorthand for a set of -f options _and_ _also_ control a 
> set of other
> > behaviours, which entail enabling, disabling, or 
> fine-tuning the parameters
> > of other optimisations that do not correspond directly to 
> -f options ?
> 
> Yeah, that's pretty accurate.  You can look through the source code
> for instances of the global flags "optimize" and "optimize_size".
> Anything you can do to improve the documentation in this regard would
> be much appreciated.  It would probably be a good move to deemphasize
> all those -f switches; they tend not to be all that useful; I consider
> their primary purpose to be working around bugs in specific
> optimizations, using -On -fno-<buggy-pass>.
> 
> zw


  Hmm, maybe it would be worthwhile to invent -f options for all these
ad-hoc tests on the optimize variables, so that the -O options then *did*
become shorthand for flag sets, and the suggestion I already made for
localising the failure with a given -O setting would actually work?


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: optimization issue about -O2 and -Os

[Phil Edwards]

On Fri, Apr 30, 2004 at 06:21:26PM +0100, Dave Korn wrote:
> 
>   Hmm, maybe it would be worthwhile to invent -f options for all these
> ad-hoc tests on the optimize variables, so that the -O options then *did*
> become shorthand for flag sets, and the suggestion I already made for
> localising the failure with a given -O setting would actually work?

We need fewer -f options, really, not more of them.

Or to put it another way:  if an optimization pass is buggy, it doesn't
deserve to have an -f option yet.


-- 
Behind everything some further thing is found, forever; thus the tree behind
the bird, stone beneath soil, the sun behind Urth.  Behind our efforts, let
there be found our efforts.
              - Ascian saying, as related by Loyal to the Group of Seventeen

Re: optimization issue about -O2 and -Os

[David Edelsohn]

>>>>> Phil Edwards writes:

Phil> On Fri, Apr 30, 2004 at 06:21:26PM +0100, Dave Korn wrote:
>> Hmm, maybe it would be worthwhile to invent -f options for all these
>> ad-hoc tests on the optimize variables, so that the -O options then *did*
>> become shorthand for flag sets, and the suggestion I already made for
>> localising the failure with a given -O setting would actually work?

Phil> We need fewer -f options, really, not more of them.

Phil> Or to put it another way:  if an optimization pass is buggy, it doesn't
Phil> deserve to have an -f option yet.

	I think this is confusing two different motivations and trying to
create a single answer for both, which will not work.

	If one considers -f options as intended only for the general user,
there probably are too many.  However, if one is performing component/unit
testing or debugging or performance tuning or providing consulting
services, there are not enough options.

	Developers and advanced users should be able to enable and disable
every optimization option at a fine granularity at compile time, not when
building GCC.  Labeling those as "-f" options and documenting them for the
general user is a separate issue.

David

Re: optimization issue about -O2 and -Os

[llewelly]

Phil Edwards <phil@codesourcery.com> writes:

> On Fri, Apr 30, 2004 at 06:21:26PM +0100, Dave Korn wrote:
> > 
> >   Hmm, maybe it would be worthwhile to invent -f options for all these
> > ad-hoc tests on the optimize variables, so that the -O options then *did*
> > become shorthand for flag sets, and the suggestion I already made for
> > localising the failure with a given -O setting would actually work?
> 
> We need fewer -f options, really, not more of them.
> 
> Or to put it another way:  if an optimization pass is buggy, it doesn't
> deserve to have an -f option yet.
[snip]

From the standpoint of a user, if an optimization pass is buggy, it
    needs an -fno option.

Re: optimization issue about -O2 and -Os

[Dale Johannesen]

On Apr 29, 2004, at 9:05 PM, Jim Wilson wrote:
> On Thu, 2004-04-29 at 19:34, Ebony Zhu wrote:
>> Have you ever been troubled in the same problem? Are you sure it's a 
>> gcc
>> bug, and not a mistake I probably made when building the cross tool?
>> (e.g. missed some important options when building gcc).
>
> If something compiled with -O2 works and something compiled with -Os
> does not work, then the logical conclusion is that the -Os option is
> buggy.

This is most likely, but it's also possible you have a source code bug 
that
happens to "work" (i.e. do what you intended) with -O2 but not -Os.
Regardless, debugging it is the right way to go.