Re: Gforth and gcc "progress"

Bernd Paysan <bernd.paysan@xxxxxx> wrote:
Andrew Haley wrote:
What would be interesting to me is a to know the most important gcc
deficiencies from the point of view of GForth and your estimate of how
significant these deficiencies are. There might well be some push-back
from gcc developers, with the claim that GForth "isn't
representative". But I'm not convinced of that, as I suspect that some
of the problems you've seen might have an impact on other code bases.
There is more to the world than SPECint.

One obvious deficiency in the current GCC is that it deals poorly with copy
propagation, and that must impact every program. The code GCC 4.1.2
compiles on x86_64 for the + primitive is a good example (and 4.2.0
compiles almost the same code):

# +
#NO_APP
leaq 8(%r15), %rax ; create AGU bubble
addq $8, %rbx ; create another AGU bubble
addq (%rax), %r14
movq %rax, %r15
.L261:
movq -8(%rbx), %rbp
.L262:
movq %rbp, %rax
jmp *%rax

The update of the address before use is a "no-no" in modern pipelined CPUs,
as it introduces a pipeline bubble. The two movq reg,reg in this example
are completely superfluous.

What I would write is:

# +
#NO_APP
addq 8(%r15), %r14
movq (%rbx), %rax ; avoid AGU bubble
addq $8, %r15
addq $8, %rbx
.L261:
jmp *%rax

Hmm, OK. Just to be clear that we are talking about the same block of
code, I've included what I think is the corresponding source code. Is
this right?

J_plus: asm(""); I_plus:

{ saved_ip=ip; asm(""); }
{
Label ca;
Cell n1;
Cell n2;
Cell n;
({cfa1=cfa; cfa=*ip;});
((n1)=(Cell)(sp[1]));
((n2)=(Cell)((sp[0])));

sp += 1;
{
# 681 "./prim"
n = n1+n2;
# 2883 "prim.i"
}

({ip++; ca=*cfa;});
(((sp[0]))=(Cell)(n));
K_plus:
({goto *ca;});
}

I'm rather worried that this may turn out to be the reload pass
performing poorly, but let's see.

Andrew.
.

Relevant Pages