Re: Measuring gcc optimizations: are they well balanced?

[Jan Hubicka <hubicka at atrey dot karlin dot mff dot cuni dot cz>]

Hi Jacob,
Your analysis seems to be somewhat oversimplified. If you take a look
at gcc sources, you may notice that there are number of optimizations
currently disabled with the comment, that they hurts the performance.
Many of them was already completely removed from the source tree.

The situation is not so simple, as you might imagine. Compiling is complex
process and in order to keep compiler resonably fast it sometimes has to
do transformations that "usually helps", but also hurts in some cases.
Also gcc supports number of platform and some optimization may be clear
win on some machines and loss on others.
(in your case most RISC platforms will like the transformed code better)

I believe that every gcc developer (including me) is aware of samples of
code, where gcc does bad job, but in many cases it is really hard to avoid
them.

In your particular example, I believe it should be possible to look at it and
maybe avoid the missoptimization, but your
mail contains number of mistakes, that makes tracking down what happends
harder.  First of all it mentions egcs-2.7.1, this is non-existent compiler.
There exist gcc-2.7.1, but it is really old. Also your internal loop as noted
in the email is infinite:

	i=0
	while (i < TOP-1)
		table[i] = table[i+1];

so please next time try to avoid such simple mistakes.
I've tried to reproduce your problem with current version of gcc using
following loop:

int TOP;
int table[100];
test()
{
  int i=1;
  while (i<TOP-1) {table[i]=table[i+1];i++;}
}

and got following code:

	.file	"t1.c"
	.version	"01.01"
gcc2_compiled.:
	.comm	TOP,4,4
	.comm	table,400,32
.text
	.align 16
.globl test
	.type	 test,@function
test:
	movl	TOP, %edx
	pushl	%ebp
	movl	%esp, %ebp
	leal	-1(%edx), %eax
	cmpl	$1, %eax
	jle	.L4
	movl	$table+4, %ecx
	subl	$2, %edx
	.align 16
.L5:
	movl	4(%ecx), %eax
	movl	%eax, (%ecx)
	addl	$4, %ecx
	decl	%edx
	jne	.L5

It is somewhat non-naturally optimized, but equivalent in number
of cycles on most modern IA-32 implementations to the lcc's code.

Honza