Re^2: Oh noooooo!!

David E. Wallace wallace at hpdtl.HP.COM
Sat Sep 30 03:28:47 AEST 1989


> jones at megatest.UUCP (Dave Jones)
> From article <1100 at cernvax.UUCP>, by hjm at cernvax.UUCP (Hubert Matthews):
> ...
> > 
> > GOTOs are ubiquitous in FORTRAN and uncommon in C.  A FORTRAN compiler
> > needs to be able to optimise in the face of GOTOs, whereas a C
> > compiler is rarely called upon so to do.
> 
> Statements like this never fail to mystify me.
> 
> So what if program A is rarely called upon to do task B?  If it is ever
> called on to do it, will it do it?
> 
> Please clarify.

An optimizer is required to produce correct code for all possible legal inputs.
If it doesn't do this, it has a bug.

An optimizer is not required to produce optimal code for all possible legal
inputs.  Thus it is perfectly acceptable for an optimizer to drop back
and punt in rare cases, by passing the (correct) unoptimized code
through unchanged.  If you can gain some other design win by doing so
(faster compiles, faster time to market, better results on more common cases),
it makes sense to do this.  This is just a performance tradeoff issue.

Walter Bright notes that goto's may be more common in machine-generated
code, such as the output of lex and yacc.  This is true, and it is a reason
to not ignore goto-containing code completely.  Any optimizations that can
be done easily should be done.  The point is that you don't need to optimize
every possible pathological case.

Dave W.



More information about the Comp.lang.c mailing list