Path: utzoo!attcan!uunet!lll-winken!lll-tis!mordor!joyce!sri-unix!garth!smryan From: smryan@garth.UUCP (Steven Ryan) Newsgroups: comp.arch Subject: Superoptimiser. Message-ID: <834@garth.UUCP> Date: 28 Jun 88 21:00:17 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> Reply-To: smryan@garth.UUCP (Steven Ryan) Organization: INTERGRAPH (APD) -- Palo Alto, CA Lines: 19 In article <7570@boring.cwi.nl> dik@cwi.nl (Dik T. Winter) writes: >In article <12171@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > > It came up with a four-68000-instruction `signum' function, > > and its versions of min and max (and minmax together) are also quite > > surprising. None of them have any branches. >(What is signum?) >Not so surprising for min and max (and minmax). However, they require a >sign extending shift, so that implementation is not possible on all >machines. Also, if a branch takes only one cycle (with delay slot), >you do not gain anything (in general). 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. Branches tend to be deadly to fast machines. Delay slots or no, it can still give the cache/instruction stack indigestion. By the way, as we continue forward into the past, the Cyber 170 macros are filled with handcoded sequences to avoid branches.