Re: Effectiveness of compilers today

Joe Buck (jbuck@forney.berkeley.edu) writes:


|> [ about the Gnu superoptimizer]


The following code sequence was presented in the original article.


|> Faster 80x86 code than the standard cmpl/seta/and for
|> ecx = ((unsigned) eax > (unsigned) edx):
|> cmpl %eax,%edx
|> sbbl %ecx,%ecx
|> negl %ecx


An interesting point. This code sequence is a well known trick regularly
used by 8086 assembly programmers 10 years back. So it should hardly
require a super-optimizer to find it. In fact, PL/M86 regularly generated
such sequences, way back in 1979! (Actually, since PL/M defined FALSE as
0xff, it didn't need the final neg.) If my memory serves me right, this
was just a carry over from PL/M80 (earlier than 1976?).


So modern compilers require a "superoptimizer" just to obtain what was
very run-of-mill code 10 years ago? I wonder if this has something to do
with the fact that modern compilers are written by software shops (FSF,
AT&T, etc.), whereas the original PL/M was written by the chip
manufacturer. So 10 years ago, the compiler writers knew the target
machine intemately, whereas now, they try and find a general solution for
all machine architectures. Nevertheless, the above optimization is a win
on most conventional architectures, so there is no excuse for GNU (and
even less for Microsoft and Borland, who make strictly Intel compilers) to
not use it.


I suspect that where the assembler programmer gets the most wins is not
the really small sequences, but in the medium length stuff. And I also
suspect that assembly programming pays off more in unorthogonal
architectures (like the 80x86) than in orthogonal ones (like the NSC
32000).
--
James Kanze email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
--

Return to the comp.compilers page.
Search the comp.compilers archives again.