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?