Re: Gforth and gcc "progress"

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

Actually, we could change our source code so that GCC has more opportunity
to avoid the second AGU bubble (it's optimized for register pressure to
make it possible to combine the jump into

jmp *-8(%rbx)

, but the way GCC 4.x handles indirect jumps prevent such an optimization,
anyway).

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
.

Relevant Pages