On 4/18/07, Joerg Wunsch <[EMAIL PROTECTED]> wrote:
As Eric Weddington wrote:
> > > And it seems to have some issues:
> > > <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528> Comments #4
> > > and #6.
> > The only real issue here is a wrong expectation: That a certain
> > combination of flags magically does the best thing for every
> > target.
No, the issue is that the -Os option is *documented* to *only* include
those optimizations that are known to not increase the code size.
My copy of the documentation says:
@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.
Note: typically.
Since that bug report shows that the inlining as implemented now
increases the code size (for that test case) for every target where it
has been tested on so far, this is clearly in violation of the rules
for -Os, and thus a regression compared to older versions of GCC
(which generally didn't perform any automatic inlining with -Os).
It shows so for this particular test case, but that does not count as
proof that the flag always causes increased code size for every test
case. When it was decided to inline at -Os, this was done because
there was proof that overall (for CSiBE) it resulted in smaller
binaries.
I spent a couple of hours to boil down the complaints of our users
(some of them still think that GCC 4 is a major step backwards for
them!, compared to GCC 3) to what really makes a meaningful bug report
(simple, reproducible). I spent another couple of hours to
demonstrate this regression basically affects *all* GCC targets (not
just AVR which I realize is by now of quite minor importance), and
what am I called for doing that?
You got an explanation from me how the inlining decisions are made,
and why that may or may not work for every target that GCC supports.
Quote (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528#c5):
Inlining decisions are based on heuristics. What works for one target may not
work quite as well for another. In this case, it seems that for AVR the
heuristics are not the best. You can tune the heuristics for this target and
let the target options override the default heuristics parameters.
And now that you've shown that for this test case GCC actually may
have regressed on every target, you've shown that perhaps the global
inlining heuristics should be changed. May well be, for all I know.
Tuning heuristics is always hard and never provably optimal.
Gr.
Steven
