Patch ping...

[Jan Hubicka]

> 
> Of course, I don't have any objection with adding a -Os -f<something> 
> option to do something that's more like "small code, except for places 
> where you think it really matters".

To some degree, I would like to avoid GCC command line explossion.  It
always seemed to me that it is resonable to make -Os optimize for size
unless explicitely stated in program to not do so.
On the other hand, at the moment it is more about infrastructure, and I
guess we all agree on the other half that -O2 + attribute cold (or other
good hint, like abort call or builtin_expect) should lead to
optimization for size

So I am happy to drop the -Os part of the plot, and make "hot" predicate
to always result false for -Os declaring whole compiled application
cold.  Later we can think of what -f option we want or what -Os
behaviour is preferrable.

As Andi mentioned, we have problem that -O2 is bit too performance
centric for average application in many cases probably making system
built with -O2 requiring more memory than it would need and thus be
slower. Though I believe we are better in this respect than many other
compilers.

It might make sense to make -O2 more code size concerned instead of
having -Omostly-small or have some -fXXX finetunning for -Os to make -Os
useable for applications where speed matters too.  But it is better to
handle this independently. Just thinking of way how to benchmark this
drive my head crazy ;)

Honza
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713