Path: utzoo!attcan!uunet!husc6!uwvax!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Duff's device, and branching into a loop
Message-ID: <13433@mimsy.UUCP>
Date: 7 Sep 88 22:21:18 GMT
References: <32941@cca.CCA.COM> <1683@dataio.Data-IO.COM>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 25

In article <1683@dataio.Data-IO.COM> bright@Data-IO.COM (Walter Bright) writes:
[branching into a loop produces irreducible flow graphs, which
are big trouble for optimisers.]
>Irreducible flow graphs occur so rarely in production code (even in code
>that is a snarl of goto's) that [splitting] is not worthwhile, and
>approach (1) or (2) [abandoning optimisation] is used.

I am curious as to where this statistic comes from, although I happen
to believe it.  Who or what measures `production code'?  Most studies
I have heard about are not as thorough as one might want.  Perhaps the
thing to do is embed such counting in a commercial compiler, and after
it has been in use for several years, read out the results.

>Some optimizers do not do flow analysis to detect loops. They rely on
>recognizing loop constructs such as for(), while() and do..while(). Since
>they cannot recognize an irreducible flow graph, they silently abandon
>optimization on *any* function with a goto in it.

This is (in my ever-so-humble opinion :-) ) entirely the wrong way to
do it.  I should note here that Walter Bright's compilers do it the right
way.  One should not be penalised for the occasional jump out to an
error return.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris