Xref: utzoo gnu.gcc:55 comp.arch:7116
Path: utzoo!attcan!uunet!labrea!decwrl!hplabs!oracle!hqpyr1!csimmons
From: csimmons@hqpyr1.oracle.UUCP (Charles Simmons)
Newsgroups: gnu.gcc,comp.arch
Subject: Re: Common Compilers for benchmarks (was: Re: benchmarking)
Keywords: gcc silicon compilers RTL MIPS
Message-ID: <474@oracle.UUCP>
Date: 3 Nov 88 10:21:12 GMT
References: <7352@wright.mips.COM> <26627@ucbvax.BERKELEY.EDU>
Sender: news@oracle.uucp
Reply-To: csimmons@oracle.UUCP (Charles Simmons)
Organization: Oracle Corporation, Belmont CA
Lines: 51

In article <26627@ucbvax.BERKELEY.EDU> shs@ji.Berkeley.EDU (Steve Schoettler) writes:
>In article <7352@wright.mips.COM> earl@mips.COM (Earl Killian) writes:
>>I think it would be interesting to benchmark various different
>>machines using gcc as the compiler.  This partially removes one
>>variable: how much performance is due to the compiler and how much to
>>the hardware.
>
>Consider that gcc compiles down into an intermediate RTL description
>of the original C code.  The RTL describes an idealized abstract machine,
>and is designed to be abstract enough so that it can be mapped into
>a variety of processors: 68K,386,370, etc.  How efficiently this RTL
>description is compiled into the target machine code reflects how
>close the abstract machine is to the actual target machine.

Um...  Seeing how I've worked on the GCC 370 compiler, I'd argue
with this point of view.  One of the really neat aspects of GCC is
that you can, in some sense, generate machine-dependent RTL code.

For example, the original RTL code doesn't have any support at all
for double word integers (or 'long long's).  But, in an early pass
of the compiler, the compiler calls a machine dependent routine to
generate intermediate RTL code.  By performing this pass, the generated
intermediate RTL code tends to provide an abstract machine that very closely
mimics the target machine.

>So, I think what you'll find from such a study is which machine most
>closely resembles the abstract machine Richard Stallman et al 
>had in mind when the RTL was designed.

There are, of course, other issues.  The 370 has various aspects
that make writing a compiler for it difficult.  In particular,
allowing subroutines that require more than 4K bytes of instructions
is somewhat tricky; and the fact that the 370 doesn't have negative
offsets makes it difficult to implement a stack on the 370 that
is compatible with the type of stack that GCC would like to implement.
(I guess what I'm saying here is that GCC does contain an abstract
machine that doesn't map real well onto the 370, and the abstract
machine is partially described by portions of the compiler that
have nothing to do with the RTL code.)

Of course, even using GCC to run all benchmarks still leaves you
open to differences in the skill of a compiler writer.  An untuned
implementation of GCC might not contain as many peephole optimizations
as would be desirable, or one of the instructions in the instruction
set may not have been described.  On the other hand, if you give me
a benchmark, it becomes relatively easy to tune GCC to run that particular
benchmark quickly.

>Steve

-- Chuck