Re: Loop Optimizations and Gotos

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]
--

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