Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.lang.c
Subject: Re: Put your code... (was Re: gotos
Message-ID: <2800@bsu-cs.UUCP>
Date: 29 Apr 88 03:54:29 GMT
References: <2597@ttrdc.UUCP> <165600043@uiucdcsb> <1988Apr27.164212.12535@utzoo.uucp>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 25

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.

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.

Perhaps one could write a special-case optimizer that works only on
switch statements, looking for and eliminating duplicate code preceding
break statements.  But if such duplicate code occurs only rarely,
having everybody's compiler include such an optimizer may be overkill,
and it might prove far simpler to do the optimization manually (i.e.,
using gotos) and keep the optimizer simple.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi