optimization/3436: severe code quality regression when compiling gforth

Anton Ertl anton@a0.complang.tuwien.ac.at
Wed Jun 27 03:27:00 GMT 2001


Denys Duchier wrote:
> 
> anton@mips.complang.tuwien.ac.at writes:
> 
> > That's quite close to optimal.  And here's what gcc-3.0 produces:
> > 
> > .L574:
> > 	movl	4(%esi), %eax
> > 	movl	__ctype_toupper, %ecx
> > 	addl	$4, %esi
> > 	leal	(%ebx,%eax), %ebx
> > 	movl	-1476(%ebp), %eax
> > 	addl	$4, %eax
> > 	movl	%eax, -1476(%ebp)
> > 	movl	-1476(%ebp), %eax
> > 	jmp	*-4(%eax)
> > 
> > There are the following suboptimalities here:
> > 
> > 1) The "movl __ctype_toupper, %ecx" is not needed here; it is present
> > in most of the primitives; maybe overly eager code motion?
> 
> This looks very much like a problem I had a while ago (in a bytecode
> emulator).  GCC somehow gets it in its head to maintain a totally
> useless invariant.  Brad Lucier suggested -fno-gcse and that worked
> fine for me.

Thanks, that eliminates this instruction; however, the other problems
are still present:

.L584:
	movl	4(%esi), %eax
	addl	$4, %esi
	leal	(%ebx,%eax), %ebx
	movl	-556(%ebp), %eax
	addl	$4, %eax
	movl	%eax, -556(%ebp)
	movl	-556(%ebp), %eax
	jmp	*-4(%eax)

- anton



More information about the Gcc-bugs mailing list