Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site desint.UUCP
Path: utzoo!linus!decvax!ittvax!dcdwest!sdcsvax!sdcrdcf!trwrb!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: net.lang.c
Subject: Re: Breaking out - the ratfor approach
Message-ID: <192@desint.UUCP>
Date: Thu, 1-Nov-84 23:44:52 EST
Article-I.D.: desint.192
Posted: Thu Nov  1 23:44:52 1984
Date-Received: Sat, 3-Nov-84 21:08:48 EST
References: <2122@usceast.UUCP> <169@desint.UUCP> <370@petsd.UUCP>
Organization: his home computer, Thousand Oaks, CA
Lines: 39

In article <370@petsd.UUCP> Joe Orost writes:

>>So tell me, folks:  do *you* have a global data flow analysis algorithm that
>>works in the presence of unrestricted goto's?
>>-- 
>>	Geoff Kuenning
>
>Yes, we have had one since 1978 in our FORTRAN VII O compiler.  Any decent
>global optimizer works on the program after all loops, block ifs, etc. have 
>been changed into GOTOs.  We even remove loop invarients from GOTO loops.

Um, oops.  I must be getting senile.  As Peter Honeyman also pointed out,
what Dijkstra was actually saying was that the unrestricted USE of GOTO's
made programs less optimizable.  For example, the sequence

		call destroyregisters (a, b)
		goto 200
	C	Top of  Loop
	100	continue
		... (a)
	200	continue
		... (b)
		if (loopmore) goto 100

cannot make any assumptions about the contents of temporary registers in
code section (b).  (I decided to use Fortran since I'm obviously senile.  The
proof is in the fact that I wrote Fortran using lowercase.)  This is a
much less serious problem.

Having egg on my face and having been shown that carefully-used goto's are
as optimizable as the funny break, I hereby withdraw all my objections and
come out in support of using goto's for this purpose.

I think I'll go punch some cards, just for old times' sake...
-- 

	Geoff Kuenning
	First Systems Corporation
	...!ihnp4!trwrb!desint!geoff