Re: GCC -On optimization passes: flag and doc issues

[Joerg Wunsch]

As Eric Weddington wrote:

> > > And it seems to have some issues:
> > >  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.  It
is all fine with me to have automatic inlining of functions if and
only if that does not increase the code size -- because, after all,
that is the main idea behind -Os: to get the smallest code size
possible.

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).

If you don't accept that to be a regression, what else are you willing
to accept?

> > Then, folks who like to complain
> > come along and report silly bugs like this,

> Wow.

I hope you just had a bad day only.  Otherwise, I might eventually
lose my trust into the mental abilities of the GCC developers.  Sorry.
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?

Sorry, but this is unbelievable.

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Re: GCC -On optimization passes: flag and doc issues

[Joerg Wunsch]

As Steven Bosscher wrote:

> Maybe you can look at the development of code size of AVR over time,
> and show a different trend, but I'd be surprised.

Most AVR users use -Os, as small code is fast code in most of the
cases on the AVR.  The `overall summary' is that GCC continuously
decreased its efficiency in code generation throughout the 3.x version
line.  It's never been a dramatic change, but with each compiler
version, the code grew by a percent or two.  Sure, bugs have been
fixed than, and obviously, the older (smaller) code had a higher
probability of being incorrect.  However, the perception of the users
(and don't underestimate their perception!) was that GCC actually got
worse over time.

With GCC 4.x (where x >= 1 so the initial regressions had already been
sorted out), there's now a completely different picture.  There are
people who easily gained 5...10 % code size in large projects, but
there are as well numerous cases where the resulting code size
increased by a similar dramatical value when switching from GCC 3.x to
4.x.  As it turns out, most (if not all) of the latter are due to the
automatic inlining that is now enabled with -Os.

This is why that ``silly'' bug report has been filed: it *is* annoying
a good number of (AVR-)GCC users, and it *is* a regression, compared
to GCC 3.x.

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Re: GCC -On optimization passes: flag and doc issues

[Joerg Wunsch]

As Ian Lance Taylor wrote:

> If the code size increases for AVR, when using -Os, when comparing an
> older release to mainline or 4.2 branch, you should report that as a
> regression in bugzilla.  Thanks.

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

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Re: GCC -On optimization passes: flag and doc issues

[Joerg Wunsch]

As Steven Bosscher wrote:

> 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.

I accept that.  To me, it appears as if GCC is currently incorrectly
computing the costs for the inlining for very small functions.  Users
of the AVR target are particularly affected by that because obviously,
their usage pattern frequently contains that kind of short functions,
which are now being inlined though that is increasing the actual
costs.

> 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.

Then, this is rather a proof to me that CSiBE does not expose the case
of very small functions well enough.

For the AVR users, we are probably happy if the target code can be
tuned enough to get a less aggressive inlining, and I think users of
large machines wouldn't care too much about a wasted byte of code or
two unless it is their typical usage pattern.

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Re: GCC -On optimization passes: flag and doc issues

[Joerg Wunsch]

As Ian Lance Taylor wrote:

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

> The relevant code is in opts.c:

>   if (optimize_size)
> {
>   /* Inlining of very small functions usually reduces total size.  */
>   set_param_value ("max-inline-insns-single", 5);
>   set_param_value ("max-inline-insns-auto", 5);
>   flag_inline_functions = 1;

> Inlining has changed considerably since then, and it is possible
> that these parameter values are no longer appropriate.  The reports
> at the time indicate space savings.

Thanks for telling me where to look for it, Ian!  It's really
appreciated.

I made a first attempt on lowering max-inline-insns-auto from 5 to 3.
I did some initial testing (using the C program and shell script in
the attachment), on a recent GCC tree built for both, the AVR target
as well as my host's native i386 target.  This appears to be at a
break-even to me:

Conditions  -Os -Os -fno-inline
target=avr, N=1, GETX= CONST_ARG:   22  26
target=i386, N=1, GETX= CONST_ARG:  38  54
target=avr, N=1, GETX=  function:   40  42
target=i386, N=1, GETX=  function:  53  69
target=avr, N=2, GETX= CONST_ARG:   30  30
target=i386, N=2, GETX= CONST_ARG:  64  64
target=avr, N=2, GETX=  function:   50  48
target=i386, N=2, GETX=  function:  79  80
target=avr, N=3, GETX= CONST_ARG:   34  34
target=i386, N=3, GETX= CONST_ARG:  74  74
target=avr, N=3, GETX=  function:   54  52
target=i386, N=3, GETX=  function:  86  87
target=avr, N=4, GETX= CONST_ARG:   38  38
target=i386, N=4, GETX= CONST_ARG:  84  84
target=avr, N=4, GETX=  function:   58  56
target=i386, N=4, GETX=  function:  93  94
target=avr, N=5, GETX= CONST_ARG:   42  42
target=i386, N=5, GETX= CONST_ARG:  94  94
target=avr, N=5, GETX=  function:   62  60
target=i386, N=5, GETX=  function:  100 101

For only a single invocation, obviously, running with -fno-inline will
always yield larger code (albeit the difference is much less on the
AVR than on the i386).

For multiple invocations, both architectures are neutral to the
-fno-inline option when invocation the function to be inlined with a
constant argument.  If instead the argument is another function
(possibly to be inlined), both architectures behave differently: the
AVR wins one instruction (two bytes) when not inlining, the i386 wins
one instruction when inlining.

The "getx()" function was a silly attempt to mimic the typical C++
access methods mentioned without really using C++.

This indicates using 3 instead of 5 might be a much more sane default.

What's that test suite that has been mentioned here, and how to run
it?

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
#define UCSRA (*(volatile unsigned char *)0x2B)
#define UDRE 5
#define UDR   (*(volatile unsigned char *)0x2C)

static void putch(char ch);

void putch(char ch)
{
  while (!(UCSRA & (1< 1
  putch(GETX()); 
# if N > 2
  putch(GETX()); 
#  if N > 3
  putch(GETX());
#   if N > 4
  putch(GETX()); 
#   endif
#  endif
# endif
#endif

  return 0;
}



run.sh
Description: Bourne shell script

Re: GCC -On optimization passes: flag and doc issues

[Joerg Wunsch]

As Ian Lance Taylor wrote:

> > What's that test suite that has been mentioned here, and how to
> > run it?

> http://www.inf.u-szeged.hu/csibe/

Thanks for the pointer.  Got it.  Alas, that tool is completely
unportable, and requires Linux to run.  It suffers from bashomania
(like using $((I--)) when the POSIX way wouldn't require much more
work), and also uses non-portable options to other Unix tools (like
the option -f for time(1)).  I'm close to give up on that :(,
partially because of not getting it to run on my FreeBSD host, and
obviously, it stands no chance to be run against an AVR target system
anyway.

The idea behind that tool is great, I only wish the authors had taken
a class in portable shell scripting before.  It's not that all the
world's a Vax these days...

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Re: GCC -On optimization passes: flag and doc issues

[Joerg Wunsch]

As Steven Bosscher wrote:

> >The idea behind that tool is great, I only wish the authors had
> >taken a class in portable shell scripting before.  It's not that
> >all the world's a Vax these days...

> Patches welcome, I guess.

Well, quite an amount of work, alas.  There's no central template in
CSiBE where this could be changed, instead, they apparently manually
changed each and any of the Makefiles etc. in the src/ subdirectories
there, so it's almost 50 files to make identical changes to.

I intended to spend my time into trying the various possible GCC
configurations (including the really promising idea Richard Guenther
proposed), not into patching the benchmark tool.  It's not that I'm a
university student anymore that has almost indefinate time at hands to
spend...  That's been 20 years ago.

Another thing is to extend CSiBE so it could be used to compile some
meaningful AVR code.  It's not that I'm lacking that kind of code, but
these manually hacked Makefiles for each tool make it kinda difficult
to adapt the benchmark suite to different sources that are more
appropriate to the AVR.

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Re: GCC -On optimization passes: flag and doc issues

[Joerg Wunsch]

As René Rebe wrote:

> >   "find | sed -i" would take most of the pain out of that if you
> > did want to try it...

> sed "-i" is an "evil" GNU extension, likewise :-)

No, it's similarly available on FreeBSD.  That would be fine with me
here, as it's only required to tweak the code, but would not be left
in the publically available kit afterwards.  However, as I already
wrote to Dave, I never got the hang of writing multiline sed scripts.
Guess even using ed(1) with a here document is more to my liking, but
I'll probably end up with a short Perl hack then.

I'm simply out of time for all this right now.  I did have a few hours
of free time slots last week that I could have spent into improving
GCC's inlining, but eventually have wasted these into first hacking
the tools instead. :-(

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Re: GCC -On optimization passes: flag and doc issues

[Joerg Wunsch]

As Richard Earnshaw wrote:

> There's no need to hack everything up.  As long as you have bash
> installed on your machine, it's straight-forward to run CSiBE on
> *BSD machines: simply invoke the makefiles with SHELL=.../bash.

That's what I did, but it doesn't help for the non-standard usage of
/usr/bin/time (-f option).  They even explicitly used /usr/bin/time
rather than bash's builtin.


As Andreas Schwab wrote:

> > ...: simply invoke the makefiles with SHELL=.../bash.

> Or (pd)?ksh, for that matter.

Did you try?  Maybe my version of pdksh is just too old, but it
doesn't grok that $((I--)) construct either.

OK, just installed ksh93, it appearently understands it.

Still, I don't see a real need for this in CSiBE as it would be simple
to replace it by the standard Posix arithmetics syntax, or even more
portably by the use of expr(1).  The time -f thing is a bit harder to
do (in particular given that bash's time(1) builtin behaves different
that the Posix time(1)).

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Re: GCC -On optimization passes: flag and doc issues

[Joerg Wunsch]

As Richard Earnshaw wrote:

> > That's what I did, but it doesn't help for the non-standard usage
> > of /usr/bin/time (-f option).  They even explicitly used
> > /usr/bin/time rather than bash's builtin.

> No, it uses whichever time program you pass to the configure script
> with the -S flag.  So just install gnu time as .../gtime and
> configure with -S .../gtime.  R.

[EMAIL PROTECTED] 2156% pwd
/junk/CSiBE
[EMAIL PROTECTED] 2157% find . -name configure
[EMAIL PROTECTED] 2158% gtime

CORRECT>time (y|n|e|a)? 

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Re: How to compare two text files? Using sed, cmp, diff, tr?

[Joerg Wunsch]

As Jonathan Wakely wrote:

> POSIX diff with the -b option should report the files as equal, I
> don't know if that's portable enough to rely on though.

I think it is.  The Single Unix Specification requires the -b option
("Cause any amount of white space at the end of a line to be treated
as a single "), and the exit status 0 for "no differences
found", 1 for "differences found", and > 1 for "an error occurred" are
also standardized.  I don't know of any (even historic) diff that
doesn't provide -b.

There's no option to suppress printing the differences to stdout
though, and redirecting the output to a null device is likely not
portable.  I don't know whether this situation already applies to
other GCC Makefiles, but perhaps the most portable way for this is to
redirect stdout to a dummy file, and delete that file afterwards.

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Re: AVR port broken on 4.3 20080215 snapshot

[Joerg Wunsch]

As Weddington, Eric wrote:

> 1. I've never been able to get svn (Cygwin command line client) to
> fully checkout gcc. By contrast, cvs works fine for me for binutils.

SVN ought to work fine without Cygwin, on plain Windows.  Just FWIW...
I've only seen issues with some proxies that don't route all the DAV
requests used by SVN's HTTP protocol, but if CVS works, you probably
don't have a proxy involved.

I'll try upgrading my own snapshot here locally, and see whether I can
find something.

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)