Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!motcsd!hpda!hpcuhb!hpcilzb!hpcea!hpdtl!wallace From: wallace@hpdtl.HP.COM (David E. Wallace) Newsgroups: comp.lang.c Subject: Re: Re^2: Oh noooooo!! Message-ID: <7020007@hpdtl.HP.COM> Date: 29 Sep 89 17:28:47 GMT References: <556@tigger.planet.bt.co.uk> Organization: HP Design Tech. Lab., Palo Alto, CA Lines: 32 > jones@megatest.UUCP (Dave Jones) > From article <1100@cernvax.UUCP>, by hjm@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.