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

[Andreas Schwab]

Please take this up with the CSiBE people.  This is highly off-topic here.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Richard Earnshaw]

On Tue, 2007-05-01 at 12:43 +0200, Joerg Wunsch wrote:
> 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)? 
> 
.../bin/create-config

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: GCC -On optimization passes: flag and doc issues

[Richard Earnshaw]

On Tue, 2007-05-01 at 09:07 +0200, Joerg Wunsch wrote:
> 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.
> 

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.

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

[Jan Hubicka]

> 
> I'd rather remove this "hack" and use the inliners code size estimator, like
> that patch from early 2005 (attached)...

Uh yes, I think it is way to go (and additionally making -O2 to
autoinline small functions like -Os does).

The patch would be OK if it still works ;)  Even if CSiBE regress, I
would still rather preffer fixing inliner code size estimations than
keeping the parameter tweaking code.

Honza
> 
> Richard.
> 
> 2005-03-02  Richard Guenther  <[EMAIL PROTECTED]>
> 
>* opts.c (decode_options): Do not fiddle with inlining
>parameters in case of optimizing for size.
>* cgraphunit.c (cgraph_check_inline_limits): If optimizing
>for size make sure we do not grow the unit-size by inlining.
>(cgraph_decide_recursive_inlining): Likewise.

> 2005-03-02  Richard Guenther  <[EMAIL PROTECTED]>
> 
>   * opts.c (decode_options): Do not fiddle with inlining
>   parameters in case of optimizing for size.
>   * cgraphunit.c (cgraph_check_inline_limits): If optimizing
>   for size make sure we do not grow the unit-size by inlining.
>   (cgraph_decide_recursive_inlining): Likewise.
> 
> Index: opts.c
> ===
> RCS file: /cvs/gcc/gcc/gcc/opts.c,v
> retrieving revision 1.94
> diff -c -3 -p -r1.94 opts.c
> *** opts.c24 Feb 2005 09:24:13 -  1.94
> --- opts.c2 Mar 2005 13:10:58 -
> *** decode_options (unsigned int argc, const
> *** 572,580 
>   
> 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;
>   
> /* We want to crossjump as much as possible.  */
> --- 572,579 
>   
> if (optimize_size)
>   {
> !   /* Inlining of functions reducing size is a good idea regardless
> !  of them being declared inline.  */
> flag_inline_functions = 1;
>   
> /* We want to crossjump as much as possible.  */
> Index: cgraphunit.c
> ===
> RCS file: /cvs/gcc/gcc/gcc/cgraphunit.c,v
> retrieving revision 1.93.2.1
> diff -c -3 -p -r1.93.2.1 cgraphunit.c
> *** cgraphunit.c  2 Mar 2005 10:10:30 -   1.93.2.1
> --- cgraphunit.c  2 Mar 2005 13:10:58 -
> *** cgraph_check_inline_limits (struct cgrap
> *** 1184,1189 
> --- 1189,1201 
> limit += limit * PARAM_VALUE (PARAM_LARGE_FUNCTION_GROWTH) / 100;
>   
> newsize = cgraph_estimate_size_after_inlining (times, to, what);
> +   if (optimize_size
> +   && newsize > to->global.insns)
> + {
> +   if (reason)
> + *reason = N_("optimizing for size");
> +   return false;
> + }
> if (newsize > PARAM_VALUE (PARAM_LARGE_FUNCTION_INSNS)
> && newsize > limit)
>   {
> *** cgraph_decide_recursive_inlining (struct
> *** 1279,1284 
> --- 1291,1297 
> struct cgraph_node *master_clone;
> int depth = 0;
> int n = 0;
> +   int newsize;
>   
> if (DECL_DECLARED_INLINE_P (node->decl))
>   {
> *** cgraph_decide_recursive_inlining (struct
> *** 1287,1294 
>   }
>   
> /* Make sure that function is small enough to be considered for inlining. 
>  */
> !   if (!max_depth
> !   || cgraph_estimate_size_after_inlining (1, node, node)  >= limit)
>   return;
> lookup_recursive_calls (node, node, &first_call, &last_call);
> if (!first_call)
> --- 1300,1309 
>   }
>   
> /* Make sure that function is small enough to be considered for inlining. 
>  */
> !   newsize = cgraph_estimate_size_after_inlining (1, node, node);
> !   if (! max_depth
> !   || newsize  >= limit
> !   || (optimize_size && newsize > node->global.insns))
>   return;
> lookup_recursive_calls (node, node, &first_call, &last_call);
> if (!first_call)

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

[Andreas Schwab]

Richard Earnshaw <[EMAIL PROTECTED]> writes:

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

Or (pd)?ksh, for that matter.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Richard Earnshaw]

On Fri, 2007-04-27 at 22:51 +0200, Joerg Wunsch wrote:
> 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.


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.

R.

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

[Dave Korn]

On 28 April 2007 16:13, Andreas Schwab wrote:

> René Rebe <[EMAIL PROTECTED]> writes:
> 
>> sed "-i" is an "evil" GNU extension, likewise :-)
> 
> Also a FreeBSD extension.

  I wasn't proposing it be put *into* the source, I was suggesting it be used
/on/ the source...

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

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

[Andreas Schwab]

René Rebe <[EMAIL PROTECTED]> writes:

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

Also a FreeBSD extension.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[René Rebe]

On Saturday 28 April 2007 13:50:01 Dave Korn wrote:
> On 27 April 2007 21:51, Joerg Wunsch wrote:
> 
> > 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.
> 
>   "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 :-)

-- 
  René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
  http://exactcode.de | http://t2-project.org | http://rene.rebe.name

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

[Dave Korn]

On 27 April 2007 21:51, Joerg Wunsch wrote:

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

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


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

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

[Steven Bosscher]

On 4/27/07, Joerg Wunsch <[EMAIL PROTECTED]> wrote:

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


Patches welcome, I guess.

Gr.
Steven

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

[Richard Guenther]

On 4/25/07, Joerg Wunsch <[EMAIL PROTECTED]> wrote:

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:


I'd rather remove this "hack" and use the inliners code size estimator, like
that patch from early 2005 (attached)...

Richard.

2005-03-02  Richard Guenther  <[EMAIL PROTECTED]>

   * opts.c (decode_options): Do not fiddle with inlining
   parameters in case of optimizing for size.
   * cgraphunit.c (cgraph_check_inline_limits): If optimizing
   for size make sure we do not grow the unit-size by inlining.
   (cgraph_decide_recursive_inlining): Likewise.
2005-03-02  Richard Guenther  <[EMAIL PROTECTED]>

	* opts.c (decode_options): Do not fiddle with inlining
	parameters in case of optimizing for size.
	* cgraphunit.c (cgraph_check_inline_limits): If optimizing
	for size make sure we do not grow the unit-size by inlining.
	(cgraph_decide_recursive_inlining): Likewise.

Index: opts.c
===
RCS file: /cvs/gcc/gcc/gcc/opts.c,v
retrieving revision 1.94
diff -c -3 -p -r1.94 opts.c
*** opts.c	24 Feb 2005 09:24:13 -	1.94
--- opts.c	2 Mar 2005 13:10:58 -
*** decode_options (unsigned int argc, const
*** 572,580 
  
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;
  
/* We want to crossjump as much as possible.  */
--- 572,579 
  
if (optimize_size)
  {
!   /* Inlining of functions reducing size is a good idea regardless
! 	 of them being declared inline.  */
flag_inline_functions = 1;
  
/* We want to crossjump as much as possible.  */
Index: cgraphunit.c
===
RCS file: /cvs/gcc/gcc/gcc/cgraphunit.c,v
retrieving revision 1.93.2.1
diff -c -3 -p -r1.93.2.1 cgraphunit.c
*** cgraphunit.c	2 Mar 2005 10:10:30 -	1.93.2.1
--- cgraphunit.c	2 Mar 2005 13:10:58 -
*** cgraph_check_inline_limits (struct cgrap
*** 1184,1189 
--- 1189,1201 
limit += limit * PARAM_VALUE (PARAM_LARGE_FUNCTION_GROWTH) / 100;
  
newsize = cgraph_estimate_size_after_inlining (times, to, what);
+   if (optimize_size
+   && newsize > to->global.insns)
+ {
+   if (reason)
+ 	*reason = N_("optimizing for size");
+   return false;
+ }
if (newsize > PARAM_VALUE (PARAM_LARGE_FUNCTION_INSNS)
&& newsize > limit)
  {
*** cgraph_decide_recursive_inlining (struct
*** 1279,1284 
--- 1291,1297 
struct cgraph_node *master_clone;
int depth = 0;
int n = 0;
+   int newsize;
  
if (DECL_DECLARED_INLINE_P (node->decl))
  {
*** cgraph_decide_recursive_inlining (struct
*** 1287,1294 
  }
  
/* Make sure that function is small enough to be considered for inlining.  */
!   if (!max_depth
!   || cgraph_estimate_size_after_inlining (1, node, node)  >= limit)
  return;
lookup_recursive_calls (node, node, &first_call, &last_call);
if (!first_call)
--- 1300,1309 
  }
  
/* Make sure that function is small enough to be considered for inlining.  */
!   newsize = cgraph_estimate_size_after_inlining (1, node, node);
!   if (! max_depth
!   || newsize  >= limit
!   || (optimize_size && newsize > node->global.insns))
  return;
lookup_recursive_calls (node, node, &first_call, &last_call);
if (!first_call)

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

[Ian Lance Taylor]

Joerg Wunsch <[EMAIL PROTECTED]> writes:

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

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

Ian

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

[Ian Lance Taylor]

Kenneth Hoste <[EMAIL PROTECTED]> writes:

> A related question: how is decided which priority a bug gets?

In general the release manager, Mark Mitchell, sets the priorities of
bugs in the bug database.  He follows general guidelines where
wrong-code is more important, primary platforms are more important,
etc.  That said, setting priorities has only a weak effect on which
bugs actually get fixed.  Which bugs are fixed is more related to
which ones catch the interest of individual developers, and which ones
are related to customers of people and organizations which provide
paid support for gcc.


> >> - the -fipa-X flags are not mentioned in the 4.1.2 documentation
> >
> > Looks like a bug.
> 
> A documentation bug you mean?

Yes.


> >> - the documentation for fmove-loop-invariants and ftree-loop-optimize
> >> mentions they are enabled at -O1 when they are not
> >
> > Actually I think they are enabled at -O1.  This is done in a slightly
> > tricky way: they default to being on, but they have no effect unless
> > the other loop optimization passes are run.  I think it would be
> > appropriate to clean this up to make the code more obvious.
> 
> Hmm, okay, thank you. Do you know of any other flags being activated
> like this in a 'hidden' way?

I don't know.  One way to find some would be to look at common.opt for
the variables which have Init(1), and consider whether they are really
enabled at all times or whether they only take effect when other flags
are turned on.  A general case is that many passes are only run when
optimization is turned on.  There are also interactions which may be
unexpected, such as the way that -frename-registers is turned on if
-funroll-loops or -fpeel-loops is used.  Look in process_options() in
toplev.c for those sorts of interactions.


> >> - When new optimization passes are completed, how is decided where
> >> they go to (-O1, -O2, -O3, -Os, none)? For example, why did funit-at-
> >> a-time switch from -O2 to -O1 a while ago? And, as I noticed from the
> >> 4.3.0 docs, why is fsplit-wide-types enabled at -O1, and not -O2? Is
> >> there some testing done, or is it just people saying "I think X
> >> belongs there"?
> >
> > Where to put optimizations is a trade-off between the amount of time
> > they take and the amount of good they do.  The testing which is done
> > is compilation time testing.
> 
> Hmm, okay. I still feel this is a bit ad-hoc. What about flags that
> don't get activated in any of the -On flags? Are these not stable
> enough yet on important architectures, or are there other reasons?

Flags which are not enabled at any optimization option are generally
considered to not pay off in significant numbers of cases: they
sometimes help and sometimes hurt.  For example, -funroll-all-loops.
Ideally, anybody who uses -funroll-all-loops would benchmark the code
with and without the option when deciding whether to use it.

We try to avoid flags which are unstable.  There have been a few here
and there over the years, but I'm not aware of any at present.  That
said obviously flags which are not turned on by default get less
testing.

But, yet, it is definitely ad-hoc.  If somebody had a more organized
proposal, it would be considered seriously.  The current assumption is
that we will converge on appropriate settings over time.

Ian

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

[Kenneth Hoste]

On 17 Apr 2007, at 16:27, Ian Lance Taylor wrote:


Kenneth Hoste <[EMAIL PROTECTED]> writes:


* When using -falign-loops or -fno-align-loops the corresponding
internal variable 'align-loops' should be set to 0 (= use default
setting) or 1 (= no aligning) resp. When parsing the various flags, a
variable 'value' is used to set (value=1) or unset (value=0) the
corresponding flag. Unfortunately, these values should be reversed
for the -falign-X flags, which isn't done, and thus using -falign-
loops causes no aligning, while -fno-align-loops causes aligning with
the default setting for the arch you're compiling for. Same problem
for -falign-jumps, -falign-labels and -falign-functions.


Ouch.  Thanks for noticing.


I hope I can fix this my self (should be fairly easy), once I get  
familiar with submitting patches.


A related question: how is decided which priority a bug gets?




Also, while trying to identify the flags enabled in the various -On
flags, I've run into incomplete or even wrong documentation regarding
the optimization passes. Some examples:

- the -fipa-X flags are not mentioned in the 4.1.2 documentation


Looks like a bug.


A documentation bug you mean?




- funit-at-a-time is still being reported as enabled in -O2 and
above, while it is already active in -O1 (this seems to fixed in the
4.3.0 docs though)


This would be a bug but it looks OK to me in 4.1.


Yes, you're right, sorry. It seems this was fixed in the 4.1.2 release.




- the documentation for fmove-loop-invariants and ftree-loop-optimize
mentions they are enabled at -O1 when they are not


Actually I think they are enabled at -O1.  This is done in a slightly
tricky way: they default to being on, but they have no effect unless
the other loop optimization passes are run.  I think it would be
appropriate to clean this up to make the code more obvious.


Hmm, okay, thank you. Do you know of any other flags being activated  
like this in a 'hidden' way?





- finline-functions is enabled at -Os, but isn't listed so


Yes, this should be documented better.  The general -finline-functions
is not enabled at -Os.  Only inlining of small functions is enabled.
This is done by setting parameters.


Yes, I've noticed the setting of the parameters. But this should  
definitely be reflected in the documentation.





- Some flags are enabled by other flags (for example, fschedule-insns
enables fsched-interblock and fsched-spec according to the docs). I
was unable to find where in the source code this is done... And
because I want to incorporate as much active On-flags as possible,
I'd like to track down for which flags this is really true, and for
which the docs are out-of-date.


-fsched-interblock and -fsched-spec default to 1 in common.opt.  But
they have no effect unless you enable a scheduling pass.


Another example of 'hidden' flag-activation. Any more?




- When new optimization passes are completed, how is decided where
they go to (-O1, -O2, -O3, -Os, none)? For example, why did funit-at-
a-time switch from -O2 to -O1 a while ago? And, as I noticed from the
4.3.0 docs, why is fsplit-wide-types enabled at -O1, and not -O2? Is
there some testing done, or is it just people saying "I think X
belongs there"?


Where to put optimizations is a trade-off between the amount of time
they take and the amount of good they do.  The testing which is done
is compilation time testing.


Hmm, okay. I still feel this is a bit ad-hoc. What about flags that  
don't get activated in any of the -On flags? Are these not stable  
enough yet on important architectures, or are there other reasons?


greetings,

K.

--

Statistics are like a bikini. What they reveal is suggestive, but  
what they conceal is vital (Aaron Levenstein)


Kenneth Hoste
ELIS - Ghent University
[EMAIL PROTECTED]
http://www.elis.ugent.be/~kehoste

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

[Steven Bosscher]

On 4/18/07, Joe Buck <[EMAIL PROTECTED]> wrote:

Perhaps the number of arguments should be taken into account as well.


We've been doing that for years.

Gr.
Steven

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

[Joe Buck]

On Wed, Apr 18, 2007 at 12:16:32AM +0100, Dave Korn wrote:
>   Sorry for butting in, but I just can't follow the reasoning here.
> Unless a function is only ever used once and is inlined at the single
> callsite, or unless the prolog and epilog are several times the size of
> the function body, isn't inlining /always/ (not just "typically", but
> actually *always*) going to increase code size?

Nope.  C++ is full of tiny functions that (for example) get or set one
value of a class.  Inlining them strictly reduces code size.

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

[Joe Buck]

On Tue, Apr 17, 2007 at 03:44:36PM -0700, Ian Lance Taylor wrote:
> 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.

Maybe there's a problem in setting the threshold in terms of
only the size of the function.  Inlining the function saves space if
the function itself is no longer than the code to pass the arguments and
do the call.  But the threshold is expressed in terms of only the
number of instructions.  For a zero-argument function, inlining a
5-instruction function will increase the code size, but if there are
3-4 arguments, the reverse is likely to be the case.

Perhaps the number of arguments should be taken into account as well.

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

[Ian Lance Taylor]

"Dave Korn" <[EMAIL PROTECTED]> writes:

>   Sorry for butting in, but I just can't follow the reasoning here.  Unless a
> function is only ever used once and is inlined at the single callsite, or
> unless the prolog and epilog are several times the size of the function body,
> isn't inlining /always/ (not just "typically", but actually *always*) going to
> increase code size?  I feel I must be missing something really obvious... is
> it just that the other optimisations that become possible on inline code
> usually compensate?

It's pretty much always going to be a win to inline
int f (int a) { return g (a); }
And while that kind of thing looks silly in isolation, it is quite
common in class methods in C++.

Ian

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

[Dale Johannesen]

On Apr 17, 2007, at 4:20 PM, Eric Christopher wrote:



increase code size?  I feel I must be missing something really  
obvious... is
it just that the other optimisations that become possible on  
inline code

usually compensate?


That or the savings from not having to save/restore registers, set  
up the frame, etc as well.


Don't forget the call and its setup.  Trivially, inlining an empty  
function is always a size win.

There actually were a couple in Spec95.

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

[Eric Christopher]

increase code size?  I feel I must be missing something really  
obvious... is
it just that the other optimisations that become possible on inline  
code

usually compensate?


That or the savings from not having to save/restore registers, set up  
the frame, etc as well.


-eric

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

[Dave Korn]

On 17 April 2007 23:27, Paul Brook wrote:

>> No, the issue is that the -Os option is *documented* to *only* include
>> those optimizations that are known to not increase the code size.
> 
> Where exactly is the documented? My documentation says It
> enables "optimisations that do not *typically* increase code size" (emphasis
> mine).

  Sorry for butting in, but I just can't follow the reasoning here.  Unless a
function is only ever used once and is inlined at the single callsite, or
unless the prolog and epilog are several times the size of the function body,
isn't inlining /always/ (not just "typically", but actually *always*) going to
increase code size?  I feel I must be missing something really obvious... is
it just that the other optimisations that become possible on inline code
usually compensate?


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

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

[Ian Lance Taylor]

Joerg Wunsch <[EMAIL PROTECTED]> writes:

> 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

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;

It was added here:
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00147.html

Top of thread:
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01350.html
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00016.html

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.

Ian

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

[Eric Weddington]

 

> -Original Message-
> From: Mike Stump [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 17, 2007 4:28 PM
> To: Eric Weddington
> Cc: 'Steven Bosscher'; gcc@gcc.gnu.org; 'Joerg Wunsch'; 
> 'Anatoly Sokolov'
> Subject: Re: GCC -On optimization passes: flag and doc issues
> 
> On Apr 17, 2007, at 2:56 PM, Eric Weddington wrote:
> > 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?
> 
> If you count again, you'll see there are more than 4 optimization  
> flags.  There are merely four in the set {-O0, -O1, -O2, -O3, - 
> Os}.  :-)  There are only 4 in the big-O set, as the poor 
> users can't  
> handle more.

Oh? I wonder how that decision was reached... 

> If you want to tune your target, well, patches welcome.

That's exactly what we're trying to do, sarcasm aside.

 
> > "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?
> 
> See override_options (aka OVERRIDE_OPTIONS) in 
> config/i386/i386.c for  
> example.  See the documentation where this is described.  If you  
> wonder around some more port files, you can find all sorts of cost  
> things and tuning things, they might give you some addition ideas.

Thanks for the suggestion, it's very much appreciated. We'll look into it.

 
> If you set up a regression tester that checks nightly for code size  
> regressions on your platform and send hate mail whenever one 
> of these  
> events happens, you would be one step closer to having no  
> regressions.  

Thanks for the suggestion. I'll see what I can do to implement it.

> If you maintain your port, and ask others that do the  
> codesize tests (CSiBE), to also test your platform (if they don't  
> already), they might be willing to do that.

Well, there's part of the problem. Somehow, I don't think that CSiBE
testsuite was designed for an 8-bit micro. It will be difficult to do a real
comparison. But it's definitely a start if we can tune things from the
backend.

Eric

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

[Eric Weddington]

 

> -Original Message-
> From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 17, 2007 4:20 PM
> To: Eric Weddington
> Cc: 'Steven Bosscher'; gcc@gcc.gnu.org; 'Joerg Wunsch'; 
> 'Anatoly Sokolov'
> Subject: Re: GCC -On optimization passes: flag and doc issues
> 
> Eric Weddington <[EMAIL PROTECTED]> writes:
> 
> > "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?
> 
> Define OPTIMIZATION_OPTIONS in the CPU.h file.  See the internal
> documentation, and examples in many backends.

Thanks for your help. We'll look into it. 
 
> 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.

Will change the bug report to reflect that.

Eric

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

[Paul Brook]

> No, the issue is that the -Os option is *documented* to *only* include
> those optimizations that are known to not increase the code size.  

Where exactly is the documented? My documentation says It 
enables "optimisations that do not *typically* increase code size" (emphasis 
mine).

Many optimizations (including inlining) are controlled by heuristics, which by 
their very nature give the "wrong" decision sometimes. The trick is to get 
the best overall settings, or the best settings for a particular target.

Paul

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

[Mike Stump]

On Apr 17, 2007, at 2:56 PM, Eric Weddington wrote:
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?


If you count again, you'll see there are more than 4 optimization  
flags.  There are merely four in the set {-O0, -O1, -O2, -O3, - 
Os}.  :-)  There are only 4 in the big-O set, as the poor users can't  
handle more.  If you want to submit a patch for the users, Genentech  
has a few openings.


If you want to tune your target, well, patches welcome.

"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?


See override_options (aka OVERRIDE_OPTIONS) in config/i386/i386.c for  
example.  See the documentation where this is described.  If you  
wonder around some more port files, you can find all sorts of cost  
things and tuning things, they might give you some addition ideas.


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.


If you set up a regression tester that checks nightly for code size  
regressions on your platform and send hate mail whenever one of these  
events happens, you would be one step closer to having no  
regressions.  If you maintain your port, and ask others that do the  
codesize tests (CSiBE), to also test your platform (if they don't  
already), they might be willing to do that.

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

[Steven Bosscher]

On 4/18/07, Joerg Wunsch <[EMAIL PROTECTED]> wrote:

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.


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

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

[Ian Lance Taylor]

Eric Weddington <[EMAIL PROTECTED]> writes:

> "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?

Define OPTIMIZATION_OPTIONS in the CPU.h file.  See the internal
documentation, and examples in many backends.

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

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.

Ian

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

[Eric Weddington]

 

> -Original Message-
> From: Steven Bosscher [mailto:[EMAIL PROTECTED] 
> 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 <[EMAIL PROTECTED]> 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

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

[Steven Bosscher]

On 4/17/07, Eric Weddington <[EMAIL PROTECTED]> wrote:

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


I was talking about code size, not compile time.

If you look at CSiBE, you can see how gcc improved for -Os over time:

   2004-01-11  2007-04-01  diff
arm-elf 385 357 -7.3%
mips-elf401 383 -4.5%
ppc-elf 367 349 -5%
sh-elf  330 317 -4%


   2004-08-08  2006-12-17  diff
arm-linux   342 337 -1.5%


   2004-12-05  2006-06-17  diff
bfin-elf314 312 -1%

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

Gr.
Steven

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

[Eric Weddington]

 

> -Original Message-
> From: Steven Bosscher [mailto:[EMAIL PROTECTED] 
> 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 <[EMAIL PROTECTED]> 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

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

[Steven Bosscher]

On 4/17/07, Eric Weddington <[EMAIL PROTECTED]> wrote:

> - finline-functions is enabled at -Os, but isn't listed so

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.
The -Ox options are "tuned" from time to time to get the best mix of
results of a certain set of targets. That does not mean it does the
best thing for all other targets. Then, folks who like to complain
come along and report silly bugs like this, when perhaps they should
also notice that the efficiency of GCC for -Os has increased
tremendeously in the past few years...

Just my US$0.02 about  this particular bug.

Gr.
Steven

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

[Kenneth Hoste]

On 17 Apr 2007, at 18:18, Eric Weddington wrote:





-Original Message-
From: Kenneth Hoste [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 17, 2007 3:23 AM
To: gcc@gcc.gnu.org
Subject: GCC -On optimization passes: flag and doc issues



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


This is exactly one of the reasons for our research: providing a  
usefull way to determine which flags should go where...
Of course, this still depends on the benchmarks used and the platform  
chosen, but still, the way it is done now it's just guessing IMHO (of  
course, using domain knowledge, but still)...


greetings,

K.

--

Statistics are like a bikini. What they reveal is suggestive, but  
what they conceal is vital (Aaron Levenstein)


Kenneth Hoste
ELIS - Ghent University
[EMAIL PROTECTED]
http://www.elis.ugent.be/~kehoste

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

[Eric Weddington]

 

> -Original Message-
> From: Kenneth Hoste [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 17, 2007 3:23 AM
> To: gcc@gcc.gnu.org
> Subject: GCC -On optimization passes: flag and doc issues

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

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

[Ian Lance Taylor]

Kenneth Hoste <[EMAIL PROTECTED]> writes:

> * When using -falign-loops or -fno-align-loops the corresponding
> internal variable 'align-loops' should be set to 0 (= use default
> setting) or 1 (= no aligning) resp. When parsing the various flags, a
> variable 'value' is used to set (value=1) or unset (value=0) the
> corresponding flag. Unfortunately, these values should be reversed
> for the -falign-X flags, which isn't done, and thus using -falign-
> loops causes no aligning, while -fno-align-loops causes aligning with
> the default setting for the arch you're compiling for. Same problem
> for -falign-jumps, -falign-labels and -falign-functions.

Ouch.  Thanks for noticing.

> * On x86, -fschedule-insns is disabled, but -fschedule-insns2 (or the
> corresponding internal flag flag_schedule_insns_after_reload) is
> still being used... The reason for disabling fschedule-insns is
> increased register pressure (and x86 has few registers already). I'm
> not sure if this a bug, but why disable -fschedule-insns and leave -
> fschedule-insns2 active? Because , according to the docs, fschedule-
> insns2 = fschedule-insns + an additional pass. Any comments on this
> are welcome...

As Steven mentioned, this is expected.  The docs are, perhaps,
slightly misleading.  -fschedule-insns2 does not imply
-fschedule-insns.  The two options are independent.  -fschedule-insns2
runs after register allocation and therefore does not increase
register pressure.

> I've file a bug report for the first issue (http://gcc.gnu.org/
> bugzilla/show_bug.cgi?id=31586), but since this is easy to fix, I'd
> like to fix it myself. The only thing holding me back is that I'm new
> at this: I've never contributed to an open source project before, and
> I'm only vaguely familiar with CVS and the likes. Is there a newbie-
> guide to contributing to GCC? How can I make sure this fix is done
> for 4.1, 4.2 _and_ 4.3?

Source code access is described at http://gcc.gnu.org/svn.html.  There
is some general, not very well organized, information on the gcc wiki
at http://gcc.gnu.org/wiki/.  You should first write the patch for
mainline (4.3).  When that is accepted, you can backport the patch to
the 4.1 and 4.2 branches.

> Also, while trying to identify the flags enabled in the various -On
> flags, I've run into incomplete or even wrong documentation regarding
> the optimization passes. Some examples:
> 
> - the -fipa-X flags are not mentioned in the 4.1.2 documentation

Looks like a bug.

> - funit-at-a-time is still being reported as enabled in -O2 and
> above, while it is already active in -O1 (this seems to fixed in the
> 4.3.0 docs though)

This would be a bug but it looks OK to me in 4.1.

> - the documentation for fmove-loop-invariants and ftree-loop-optimize
> mentions they are enabled at -O1 when they are not

Actually I think they are enabled at -O1.  This is done in a slightly
tricky way: they default to being on, but they have no effect unless
the other loop optimization passes are run.  I think it would be
appropriate to clean this up to make the code more obvious.

> - finline-functions is enabled at -Os, but isn't listed so

Yes, this should be documented better.  The general -finline-functions
is not enabled at -Os.  Only inlining of small functions is enabled.
This is done by setting parameters.

> - Some flags are enabled by other flags (for example, fschedule-insns
> enables fsched-interblock and fsched-spec according to the docs). I
> was unable to find where in the source code this is done... And
> because I want to incorporate as much active On-flags as possible,
> I'd like to track down for which flags this is really true, and for
> which the docs are out-of-date.

-fsched-interblock and -fsched-spec default to 1 in common.opt.  But
they have no effect unless you enable a scheduling pass.

> - When new optimization passes are completed, how is decided where
> they go to (-O1, -O2, -O3, -Os, none)? For example, why did funit-at-
> a-time switch from -O2 to -O1 a while ago? And, as I noticed from the
> 4.3.0 docs, why is fsplit-wide-types enabled at -O1, and not -O2? Is
> there some testing done, or is it just people saying "I think X
> belongs there"?

Where to put optimizations is a trade-off between the amount of time
they take and the amount of good they do.  The testing which is done
is compilation time testing.

-funit-at-a-time was moved from -O2 to -O1 because we are likely to
make it the default in all cases, including -O0.  Making
-funit-at-a-time the default will simplify several cases in the
compiler.  It is already the default in all cases for C++.

-fsplit-wide-types is at -O1 because it is normally cheap in terms of
compilation time.  It doesn't do anything if there are no "long long"
local variables in the function (or, more generally, no variables
whose type is such that they are twice the width of a general
register).

Ian

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

[Steven Bosscher]

On 4/17/07, Kenneth Hoste <[EMAIL PROTECTED]> wrote:

* On x86, -fschedule-insns is disabled, but -fschedule-insns2 (or the
corresponding internal flag flag_schedule_insns_after_reload) is
still being used... The reason for disabling fschedule-insns is
increased register pressure (and x86 has few registers already). I'm
not sure if this a bug, but why disable -fschedule-insns and leave -
fschedule-insns2 active? Because , according to the docs, fschedule-
insns2 = fschedule-insns + an additional pass. Any comments on this
are welcome...


-fschedule-insns2 is scheduling after register allocation.  Register
pressure is not a problem after register allocation ;-)  You just have
more constraints in your scheduling dependency graph.

Gr.
Steven

GCC -On optimization passes: flag and doc issues

[Kenneth Hoste]

Hiya,

I'm doing research on which optimization passes to enable in the  
various -On flags, and I've stumbled onto a/some minor bug(s) and  
problems with the GCC documentation for the 4.1.2 version:


* When using -falign-loops or -fno-align-loops the corresponding  
internal variable 'align-loops' should be set to 0 (= use default  
setting) or 1 (= no aligning) resp. When parsing the various flags, a  
variable 'value' is used to set (value=1) or unset (value=0) the  
corresponding flag. Unfortunately, these values should be reversed  
for the -falign-X flags, which isn't done, and thus using -falign- 
loops causes no aligning, while -fno-align-loops causes aligning with  
the default setting for the arch you're compiling for. Same problem  
for -falign-jumps, -falign-labels and -falign-functions.


* On x86, -fschedule-insns is disabled, but -fschedule-insns2 (or the  
corresponding internal flag flag_schedule_insns_after_reload) is  
still being used... The reason for disabling fschedule-insns is  
increased register pressure (and x86 has few registers already). I'm  
not sure if this a bug, but why disable -fschedule-insns and leave - 
fschedule-insns2 active? Because , according to the docs, fschedule- 
insns2 = fschedule-insns + an additional pass. Any comments on this  
are welcome...


I've file a bug report for the first issue (http://gcc.gnu.org/ 
bugzilla/show_bug.cgi?id=31586), but since this is easy to fix, I'd  
like to fix it myself. The only thing holding me back is that I'm new  
at this: I've never contributed to an open source project before, and  
I'm only vaguely familiar with CVS and the likes. Is there a newbie- 
guide to contributing to GCC? How can I make sure this fix is done  
for 4.1, 4.2 _and_ 4.3?


Also, while trying to identify the flags enabled in the various -On  
flags, I've run into incomplete or even wrong documentation regarding  
the optimization passes. Some examples:


- the -fipa-X flags are not mentioned in the 4.1.2 documentation
- funit-at-a-time is still being reported as enabled in -O2 and  
above, while it is already active in -O1 (this seems to fixed in the  
4.3.0 docs though)
- the documentation for fmove-loop-invariants and ftree-loop-optimize  
mentions they are enabled at -O1 when they are not

- finline-functions is enabled at -Os, but isn't listed so

I can imagine few people care about the exact flags enabled at -On,  
but why list wrong information which will only confuse people (as it  
did for me).


Last but not least, I have some questions:

- Some flags are enabled by other flags (for example, fschedule-insns  
enables fsched-interblock and fsched-spec according to the docs). I  
was unable to find where in the source code this is done... And  
because I want to incorporate as much active On-flags as possible,  
I'd like to track down for which flags this is really true, and for  
which the docs are out-of-date.


- When new optimization passes are completed, how is decided where  
they go to (-O1, -O2, -O3, -Os, none)? For example, why did funit-at- 
a-time switch from -O2 to -O1 a while ago? And, as I noticed from the  
4.3.0 docs, why is fsplit-wide-types enabled at -O1, and not -O2? Is  
there some testing done, or is it just people saying "I think X  
belongs there"?


greetings,

Kenneth

--

Statistics are like a bikini. What they reveal is suggestive, but  
what they conceal is vital (Aaron Levenstein)


Kenneth Hoste
ELIS - Ghent University
[EMAIL PROTECTED]
http://www.elis.ugent.be/~kehoste