Xref: utzoo gnu.gcc:1759 comp.compilers:1046
Path: utzoo!utgpu!watserv1!watmath!uunet!samsung!uakari.primate.wisc.edu!dali.cs.montana.edu!mintaka!snorkelwacker!spdcc!esegue!compilers-sender
From: mike@tuvie (Inst.f.Techn.Informatik)
Newsgroups: gnu.gcc,comp.compilers
Subject: Re: GCC SUN-4 code speed
Keywords: benchmarks, gcc
Message-ID: <1990Jul14.230954.14607@esegue.segue.boston.ma.us>
Date: 14 Jul 90 23:09:54 GMT
References: <1016@soleil.UUCP> <37555@ucbvax.BERKELEY.EDU>
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: mike@tuvie (Inst.f.Techn.Informatik)
Followup-To: gnu.gcc,comp.compilers
Organization: Technical University of Vienna, AUSTRIA
Lines: 27
Approved: compilers@esegue.segue.boston.ma.us

In article <1016@soleil.UUCP> gendel@soleil.UUCP (Gary Gendel) writes:
>SUN (cc -O2)
>GCC 1.37.1 (gcc -O) 12% slower, same size executable
>GCC 1.37.1 (gcc -O -fstrength-reduce -finline-functions -fforce-mem)
>	6% slower, 50% larger executable.

If you look at gcc and compare it with the Dragon book's description of a
code generator generator, you will find aut that gcc has just about
everything a code geneator generator needs to have. Specification of 
code to be matched, semantic attributes, constraints for operands, the
ability to simply emit a constant pattern or to use a piece of code to 
find the exact instruction...

Note that if you look at gcc as a code generator generator, it is doing very
well indeed. Most generators cannot boast getting roughly equivalent 
(or in some cases even better) performance than an equivalent hand-coded
program. 
			bye,
				mike

Michael K. Gschwind             mike@vlsivie.at
Technical University, Vienna    mike@vlsivie.uucp
Voice: (++43).1.58801 8144      e182202@awituw01.bitnet
Fax:   (++43).1.569697
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus| world}!esegue.  Meta-mail to compilers-request@esegue.