This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: GCC -On optimization passes: flag and doc issues
> -----Original Message-----
> From: Steven Bosscher [mailto:stevenb.gcc@gmail.com]
> Sent: Tuesday, April 17, 2007 2:52 PM
> To: Eric Weddington
> Cc: Kenneth Hoste; gcc@gcc.gnu.org
> Subject: Re: GCC -On optimization passes: flag and doc issues
>
> On 4/17/07, Eric Weddington <eweddington@cso.atmel.com> wrote:
> > > - finline-functions is enabled at -Os, but isn't listed so
> >
> > 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.
> The -Ox options are "tuned" from time to time to get the best mix of
> results of a certain set of targets.
Well this begs the question of why, when there are so many different
targets, are there are only 4 optimization flags (1,2,3,s), especially when
they only get tuned to certain targets? I know, "patches are welcome". ;-)
> That does not mean it does the
> best thing for all other targets.
Bug #31528, comment #5:
"Also, as you mention the target code has a chance to tune this ..., can you
give me a hint about
where to look for these knobs? I might give it a try to see whether I
can find a more optimal set of parameters."
This was in response to your comment in #4. Do you have any concrete
suggestions?
> Then, folks who like to complain
> come along and report silly bugs like this,
Wow. Perhaps there is someone else here on the list who might point us in
the right direction, that doesn't think this is a silly bug, or that perhaps
thinks that we might be serious about getting this fixed for the AVR.
There is concerted effort to get the AVR port in shape wrt. fixing
outstanding bugs, updating the backend, regular regression testing, etc. One
of our goals is to propose the AVR to the "secondary platform" status,
hopefully in the next six months. The AVR is a popular GCC target, with
distros on FreeBSD, Linux, Windows, Mac OS X, it can build for Solaris, and
there have been at least 51,560 downloads in the last 2 months of the
Windows distro alone:
<http://sourceforge.net/project/stats/detail.php?group_id=68108&ugn=winavr&t
ype=prdownload&mode=60day&package_id=0>
> when perhaps they should
> also notice that the efficiency of GCC for -Os has increased
> tremendously in the past few years...
That is what you think is important. To AVR users, compile time could
increase by 100% and they wouldn't care, but they do care when there is a
compiled code size regression of even 1%. Yes, part of it is the
responsibility of the port, but there are other target-independent portions
that affect this too. It would be nice if GCC could try to take all users
into consideration.
Eric Weddington