Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdahl!chuck
From: chuck@amdahl.uts.amdahl.com (Charles Simmons)
Newsgroups: comp.arch
Subject: Re: Superoptimiser.
Message-ID: <91odrecXKL1010YEOek@amdahl.uts.amdahl.com>
Date: 29 Jun 88 23:24:56 GMT
References: <1941@pt.cs.cmu.edu> <3208@ubc-cs.UUCP> <1986@pt.cs.cmu.edu> <754@garth.UUCP> <12171@mimsy.UUCP> <7570@boring.cwi.nl> <834@garth.UUCP>
Reply-To: chuck@amdahl.uts.amdahl.com (Charles Simmons)
Organization: Amdahl Corporation, Sunnyvale  CA
Lines: 19

In article <834@garth.UUCP> smryan@garth.UUCP (Steven Ryan) writes:
 >The article was interesting, but  the technique does not appear ready for
 >compilers. In the article, the optimiser was used as standalone program that
 >was fed small pieces of code.

yeah...  The authors basically suggested using the results of the
standalone program to do things similar to peephole optimization,
or writing code sequences for the GNU backend, or providing help
in figuring out cute instruction sequences to use in your innermost
handcoded loop.

 >Branches tend to be deadly to fast machines. Delay slots or no, it can still
 >give the cache/instruction stack indigestion.

Gosh!  You guys aren't thinking big enough.  How about multiple
parallel pipelines to compute all the various instruction threads
in parallel and just keep the results of the one that is actually
taken?  Takes Big Bucks?  Sure.  But when you're using gallium
arsenide, who cares?