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