Re: Loop Optimizations and Gotos

hrubin@stat.purdue.edu (Herman Rubin)
Fri, 17 Nov 1995 17:16:45 GMT

          From comp.compilers

Related articles
Loop Optimizations and Gotos jra@gensym.com (1995-11-08)
Re: Loop Optimizations and Gotos burley@cygnus.com (1995-11-12)
Loop Optimizations and Gotos dave@occl-cam.demon.co.uk (Dave Lloyd) (1995-11-12)
Re: Loop Optimizations and Gotos cliffc@ami.sps.mot.com (1995-11-13)
Re: Loop Optimizations and Gotos cdg@nullstone.com (1995-11-13)
Re: Loop Optimizations and Gotos faiman@zko.dec.com (1995-11-16)
Re: Loop Optimizations and Gotos hrubin@stat.purdue.edu (1995-11-17)
Re: Loop Optimizations and Gotos j-grout@glibm9.cen.uiuc.edu (1995-11-17)
Re: Loop Optimizations and Gotos baynes@ukpsshp1.serigate.philips.nl (1995-11-20)
Re: Loop Optimizations and Gotos plong@perf.com (Paul Long) (1995-11-21)
Re: Loop Optimizations and Gotos preston@tera.com (1995-11-21)
Re: Loop Optimizations and Gotos cliffc@ami.sps.mot.com (1995-11-21)
Re: Loop Optimizations and Gotos cliffc@ami.sps.mot.com (1995-11-22)
[4 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: hrubin@stat.purdue.edu (Herman Rubin)
Keywords: C, optimize, comment
Organization: Purdue University Statistics Department
References: 95-11-076 95-11-107
Date: Fri, 17 Nov 1995 17:16:45 GMT

Dave Lloyd <dave@occl-cam.demon.co.uk> wrote:
>It's simple - don't use goto. Many compilers have extra levels of
>optimisation that only kick in when a control construct can be
>clearly recognised that are not feasible in general for gotos. Many
>compilers won't make any attempt to preserve registers across
>arbitrary branches but will preserve them around loops and
>conditionals. And as for loop unrolling, invariant hoisting, strength
>reduction etc., few compilers will handle these on the raw branch
>structure alone - I suspect that the prevalence of structured
>programming these days means that such optimisations on raw gotos are
>now a province only of old FORTRAN compilers (and even those tended
>to benefit from the source being despagged first).


I suggest then that the fault is in the compiler writers. There
are many things which can be done by gotos which eliminate gross
inefficiencies which cannot be done by the current structure.


How can one avoid many unnecessary steps when there are numerous
logical exits from a block? One case of this is entrance to a
state machine; this and the progress within that program does
not require that the state be known other than by location in
the code, and the state variable and the associated switch
statements are not needed. Can a compiler eliminate these?
Can an optimizing compiler remove these? Not by any means
I can think of with "structured" programming.


When discussing an optimizing compiler, efficiency is the target.
Do we need to eliminate optimizations made by the human?
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
hrubin@stat.purdue.edu Phone: (317)494-6054 FAX: (317)494-0558
[Herman's opinions on the merits of gotos have been argued at length before and
I'd rather not rehash the arguments here again. -John]
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.