Re: Loop Optimizations and Gotos

baynes@ukpsshp1.serigate.philips.nl writes:
[snip:C for statements are likely to be better optimized than while
statements]


In our Standard C compilers for DSPs, the front end translates all
high-level constructs, including the for statement, into low-level
constructs, such as conditional and unconditional branches, within
basic blocks. The back end recognizes loops and other high-level
idioms and performs optiimzations and generates code accordingly. The
techniques for doing this are well established, and the results are
really quite good (how's that for an objective performance metric?
:-) ). If the posts here are representative, I'm surprised to hear
that this isn't more common with C compilers.


There was a letter, I believe, in a recent issue of CACM, that said
that the C for statement is not really an iteration statement. And
this is true if you think about it. The for statement is an idiom for
_some_ code that executes before a while statement, followed by the
while statement that tests _something_, with _some more_ code at the
bottom of the loop. It's quite common for programmers put all sorts
of things in the three expressions of a for statement that have
nothing to do with iterating through a loop. Hey, I do it, too,
sometimes.


My point is that the C for statement doesn't give a compiler very
much reliable information concerning loop processing. For example,
sometimes the initialization and stepping code is provided in the for
statement, but the exit is performed with if and break statements
within the loop. I suppose the for statement localizes it somewhat,
but I think that a compiler might even have an easier time of it if
it fends for itself and attempts to figure out what code surrounding
a cyclic sequence of basic blocks is relevant to the loop.


Paul_Long@ortel.org
plong@perf.com
http://www.teleport.com/~pciwww/
--

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