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.