Re: different results with different f77 optimizers

cliffc@ami.sps.mot.com (Cliff Click)
Thu, 5 Oct 1995 21:57:32 GMT

          From comp.compilers

Related articles
different results with different f77 optimizers keyes@chem.bu.edu (Tom Keyes) (1995-09-24)
Re: different results with different f77 optimizers ah739@cleveland.Freenet.Edu (1995-09-29)
Re: different results with different f77 optimizers roberson@hamer.ibd.nrc.ca (1995-09-30)
Re: different results with different f77 optimizers cliffc@ami.sps.mot.com (1995-10-05)
Re: different results with different f77 optimizers preston@tera.com (1995-10-06)
| List of all articles for this month |

Newsgroups: comp.sys.sgi.apps,comp.compilers
From: cliffc@ami.sps.mot.com (Cliff Click)
Keywords: Fortran, optimize
Organization: none
References: 95-09-146 95-10-026
Date: Thu, 5 Oct 1995 21:57:32 GMT

ah739@cleveland.Freenet.Edu (Leslie J. Somos) writes:


> See CMG Transactions (CMG=Computer Measurement Group)
> number 52, Spring 1986, article "Do Fortran Compilers Really Optimize?"
> by Dr. David S. Lindsay.
> He compares optimized and unoptimized versions of Fortran code
> specifically coded to be optimizable, on commercial compilers.
> Quote from his Conclusion:
> "1. Compiler optimization of generated code is haphazard at best.
> 2. Compiler optimization if _not_ a mature technology, at least
> not if IBM's VS FORTRAN and DEC's VAX/VMS FORTRAN are representative.
> 3. Trade, technical, and academic sources have no basis for their
> dogma about how all optimizing compilers do so-and-so.
> 4. Empirical tests are _badly_ needed to verify vendors' claims of
> their compilers' generation of optimized code.
> 5. Empirical tests are probably also the only way to improve
> optimization technology.
> 6. Academics should have their students run tests, not just
> learn techniques."
>
> (The article is from 1986, I have no idea if this address is stale.)
> [I also wonder if the optimization biz has advanced any in the past decade.
> I sure hope so. -John]


Well, I've certainly seen a lot of easy and old optimizations missed
or done poorly by a number of compilers. Alas, optimizing compilers
are big, and big software moves slowly. Nonetheless, the state of
optimizers _has_ improved in the last decade. I no longer use the
'register' keyword - compilers almost always get key values into
registers. Many compilers do some memory heirarchy transformations -
a must for matrix multiply and big SpecFP numbers.


I think the trend is that new optimizations show up, but improved
versions of old ones are very slow to appear. Most folks do some kind
of local value numbering; many fewer do global value numbering. Most
folks fold constants, very few do global constant propagation. Most
folks do induction variable elimination on addressing expressions in
loops; fewer use the more generic algorithm that handles constant
multiplies in loops (even multiply by 4! This crops up when you are
doing multi-dimensional arrays in C).


Cliff


P.S. My "test case compilers" include gcc 2.6.x, an older IBM xlc, an
older Sun cc, HP's cc, and Motorola's cc - not an exhaustive list fer
sure, and a little out of date. Anyone want to post a summary of more
modern compilers?
--
Cliff Click Compiler Researcher & Designer
RISC Software, Motorola PowerPC Compilers
cliffc@risc.sps.mot.com (512) 891-7240
--


Post a followup to this message

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