Path: utzoo!mnetor!uunet!husc6!bloom-beacon!athena.mit.edu!peter
From: peter@athena.mit.edu (Peter J Desnoyers)
Newsgroups: comp.lang.c
Subject: Re: Put your code... (was Re: gotos
Message-ID: <4972@bloom-beacon.MIT.EDU>
Date: 29 Apr 88 15:45:27 GMT
References: <2597@ttrdc.UUCP> <165600043@uiucdcsb> <1988Apr27.164212.12535@utzoo.uucp> <2800@bsu-cs.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: peter@athena.mit.edu (Peter J Desnoyers)
Organization: Massachusetts Institute of Technology
Lines: 26

In article <2800@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
+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.
+
+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.
+-- 
+Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi

The Apollo C compiler performs this optimization. It makes debugging
at the source level tons of fun - you jump by some magic from one case
to another. I don't know how it does it - if I were given the task, I
would write a switch compress routine that compared each case
backwards (subject to constraints) and found the longest matches. 


				Peter Desnoyers
				peter@athena.mit.edu