Re: Loop Optimizations and Gotos

burley@cygnus.com (Craig Burley)
Sun, 12 Nov 1995 05:38:07 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)
[9 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: burley@cygnus.com (Craig Burley)
Keywords: optimize
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
References: 95-11-076
Date: Sun, 12 Nov 1995 05:38:07 GMT

jra@gensym.com (Jim Allard) writes:


      [...] With some work we can identify these
      loops by a pattern matching scheme that will get most of the commonly
      used loop idioms and then translate those as FOR or WHILE loops.


      We've had a debate here about whether this work is worth it. One
      group believes that most compilers today can identify loops from the
      flow of control through GOTO statements, and then perform loop
      optimizations. Another group (myself included) believe that while
      such sufficiently smart compilers might be imagined in practice they
      are rare in the commercial world, and that most compilers today need
      the "hint" that FOR or WHILE give them in order to trigger loop
      optimization techniques.


gcc doesn't seem to treat a low-level translation of a "for" loop
exactly as it would the equivalent "for" loop, as far as I can tell
(but I'm not yet a gcc expert). So I think that you're right as far
as gcc is concerned, and perhaps for many or most C compilers,
since C has had looping constructs throughout its history (at least
as far as it applies to earlier subsets of the language).


But the Numerix Fortran Optimizing Compiler, on which I did work for
a while, definitely did convert low-level GOTO-laden code up to the
higher loop constructs. (This compiler targeted a 128-bit-wide VLIW
architecture, the Numerix 432, 464, and 332 processors.)


In fact, what this compiler did was to first LOWER all the DO loops
to their primitive (IF/GOTO-based) equivalents, then RAISE all the
primitive stuff up to loops as much as it reasonably could. It did
this because the design of the compiler was such that it compiled
from the innermost loops outward, and was definitely willing to spend
lots of time trying different strategies for optimizing inner loops
than it did outer loops and/or straightline code.


>From what I gathered at the time, the reason to RAISE primitive stuff
to higher-level constructs in Fortran is that _lots_ of old Fortran
code exists that uses no looping constructs -- because it was written
before they existed or were considered "safe" by the code authors.


If you're not particularly concerned about old Fortran code, or some
such thing, then maybe it isn't worth it. But for your project, maybe
it is anyway, and it indeed doesn't seem to hard, especially if all
you're doing is recognizing particular patterns your code generator
actually generates, not any old weird thing somebody throws at it.


Anyway, my small amount of experience with compiler internals suggests a
50% likelihood that a given optimizing compiler will find loop constructs
where they are not explicitly used. Your mileage WILL vary. ;-)
--


James Craig Burley, Software Craftsperson burley@gnu.ai.mit.edu
--


Post a followup to this message

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