Xref: utzoo misc.misc:6208 comp.misc:6127
Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!agate!bionet!ig!arizona!mike
From: mike@arizona.edu (Mike Coffin)
Newsgroups: misc.misc,comp.misc
Subject: Re: The "evil" GOTO (Was: 25 Years of BASIC)
Message-ID: <10888@megaron.arizona.edu>
Date: 17 May 89 16:13:36 GMT
References: <554@laic.UUCP>
Organization: U of Arizona CS Dept, Tucson
Lines: 31

From article <554@laic.UUCP>, by darin@nova.laic.uucp (Darin Johnson):
> Another point.  GOTO's don't get along well with optimizers.  Either
> the optimizer gives up on some optimizations, or it spends lots of
> extra time.

There is no reason that gotos should cause problems for a compiler,
unless the programmer uses them to produce irreducible flow graphs.
In particular, using gotos to break out of nested loops should not
cause problems.  If the mere presence of a goto causes the the
compiler to give up, it isn't much of a compiler.

> Of course, in C, a break or continue cause the same problems to
> a lesser degree.

Break and continue do not create irreducible flow graphs.

> Optimizers can usually do more with languages like Pascal and ADA,
> because loops are easily recognized, a FOR statement isn't shorthand
> for a WHILE statement, etc.

Modern optimizing compilers generally turn everything into a graph of
basic blocks almost immediately.  The optimizations depend on the
topology of the resulting graph, not where it came from.  In
particular, the standard algorithms for data-flow analysis require the
graph to be reducible, so may compilers punt if they are given an
irreducible flow graph.  See any of the standard compiler books for
details.
-- 
Mike Coffin				mike@arizona.edu
Univ. of Ariz. Dept. of Comp. Sci.	{allegra,cmcl2}!arizona!mike
Tucson, AZ  85721			(602)621-2858