|[8 earlier articles]|
|Re: Loop Optimizations and Gotos firstname.lastname@example.org (1995-11-20)|
|Re: Loop Optimizations and Gotos email@example.com (Paul Long) (1995-11-21)|
|Re: Loop Optimizations and Gotos firstname.lastname@example.org (1995-11-21)|
|Re: Loop Optimizations and Gotos email@example.com (1995-11-21)|
|Re: Loop Optimizations and Gotos firstname.lastname@example.org (1995-11-22)|
|Re: Loop Optimizations and Gotos Paul_Long@ortel.org (1995-11-23)|
|Re: Loop Optimizations and Gotos email@example.com (1995-11-27)|
|Re: Loop Optimizations and Gotos firstname.lastname@example.org (Dave Lloyd) (1995-11-27)|
|Re: Loop Optimizations and Gotos email@example.com (1995-11-29)|
|From:||firstname.lastname@example.org (Bill Leonard)|
|Organization:||Harris Computer Systems, Ft. Lauderdale FL|
|Date:||Mon, 27 Nov 1995 19:45:03 GMT|
> The technology exists for reconstructing loops and is probably used in
> (older?) fortran compilers as many loops in fortran have to be constructed
> using GOTO. I expect many C compilers may have inherited the technology and
> will attempt to do this. However compilers written directly as C compilers
> are quite likly to use the structure provided by the programer and not try and
> reconstruct their own.
Many modern compilers are built using a common backend that can service
multiple languages. Those compilers are, I would think, much less likely
to build in assumptions about particular language constructs. For example,
our (Harris) compilers discover loops no matter how they were constructed,
partly because the input languages (C, Fortran, Ada) have varying semantics
in their loop constructs. It is much easier for us to discover loops with
properties we are interested in than try to handle the semantics of each
language's loop constructs (and the variations thereof).
> 1: It can flatten down the code into basic blocks (with no jumps in them) and
> work on these finding its own loops and other structures. This is typical of
> compilers for unstructured languages though it can be used on structured
> languages too. This is able to cope with almost anything, but tends to lose
> any hints that can be gained from how the programer wrote the code (eg using
> 'for' loops).
It may be typical of compilers for unstructured languages, but it is
also typical of multi-language compilers.
It need not lose any hints from how the programmer wrote the code.
> 2: It can use the stucture of the language working recursively on the
> structure tree of the parsed code. It the input code is perfectly structured
> (each block has one way in and one way out) then it makes a clean and
> efficent compiler which can easily look for specifc constructs such for loops
> with simple iterators.
The hints you think you might be getting could be wrong and, in general,
have to be verified anyway. For instance, from a C 'for' loop you know
almost nothing about the control variable: it can be modified within the
loop in addition to, or in lieu of, incrementing in the loop header; such
modification can be conditional; the loop can still be exited "early" based
on tests unrelated to the control variable; etc.
If the language has a goto statement that can exit the loop, that kills a
lot of what you can assume from any loop structure.
So what are you gaining from the high-level loop structure? Not much,
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
Return to the
Search the comp.compilers archives again.