[Bug c++/47658] -Os generates bigger code than -O2/3 for many small inline functions (objects)

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47658

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-02-09 20:12:20 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > It works for me, 
> 
> what do you mean by "works" ?:)

works as "expected" ;)  At -Os we inline to remove abstraction penalty
which usually causes code size savings.  More inlining in 90% of all
cases increases code-size.  As we can't really know at the time of
inlining whether we will hit the remaining 10% (without doing both
inlining and not inlining and later throwing away the larger variant)
we choose the heuristics that usually produce the smallest possible code.

> > the abstraction is completely eliminated by early inlining.
> > At -Os we do not inline E::foo2 into E::foo1 but that isn't abstraction and
> > it isn't easily visible that this is profitable.  That results in the
> > -Os code being around 10% larger than -O2 code.
> 
> and this imho is the problem. As -Os suggests, code should be as small as it's
> posiible. So i expect that if I use Os, the code will be the smallest that gcc
> can produce. However in this example I have to use -O2 or even -O3 to get the
> smallest code, and it's misleading.

But expected - perfection is not achievable here.

So to say, this bug is either WORKSFORME (as expected) or WONTFIX (aka,
it's impossible to generate the "smallest possible").

Citing the documentation:

@item -Os
@opindex Os
Optimize for size.  @option{-Os} enables all @option{-O2} optimizations that
do not typically increase code size.  It also performs further
optimizations designed to reduce code size.

It says "Optimize for size", not "Produce smaller code than -O2 or -O3
in all cases".