Path: utzoo!mnetor!uunet!lll-winken!lll-tis!oodis01!uplherc!sp7040!obie!wes
From: wes@obie.UUCP (Barnacle Wes)
Newsgroups: comp.lang.c
Subject: Re: Put your code... (was Re: gotos
Message-ID: <211@obie.UUCP>
Date: 1 May 88 23:51:27 GMT
References: <2597@ttrdc.UUCP> <165600043@uiucdcsb> <2800@bsu-cs.UUCP>
Organization: Great Salt Lake Yacht Club, north branch
Lines: 26
Summary: Optimizing for space or speed?

In article <1988Apr27.164212.12535@utzoo.uucp> henry@utzoo.uucp (Henry
Spencer) writes:
| It doesn't take much of an optimizer
| to notice that the instruction sequences preceding an unconditional control-
| flow merge are identical, and condense them into one by branching to the
| beginning of the sequence rather than the end.  Any peephole optimizer
| worthy of the name ought to be willing to do this.

In article <2800@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) replies:
> My reading of the original article by kenny@uiucdcsb.cs.uiuc.edu is
> that kenny's example (a CPU simulator) would duplicate code in such a
> way that a peephole optimizer would not find it.  A peephole optimizer
> scans the code through a window of limited size, and rearranges code in
> that window so that the net effect of the window remains unchanged.  I
> don't think you can remove duplicate code in different places this
> way.

This form of optimization is called "common subexpression removal."
It is quite often used to optimize for space (less code space is
required, obviously).  It would NOT commonly be used if you are
looking for the utmost in speed, the time spent jumping into/out of
the common code does not make for faster programs.
-- 
    /\              -  "Against Stupidity,  -    {backbones}!
   /\/\  .    /\    -  The Gods Themselves  -  utah-cs!uplherc!
  /    \/ \/\/  \   -   Contend in Vain."   -   sp7040!obie!
 / U i n T e c h \  -       Schiller        -        wes