Related articles |
---|
[2 earlier articles] |
Re: why not inline all functions? p.toland@computer.org (Phillip Toland) (1998-06-11) |
Re: why not inline all functions? f81@ix.urz.uni-heidelberg.de (Joerg Schoen) (1998-06-11) |
Re: why not inline all functions? bje@cygnus.com (Ben Elliston) (1998-06-11) |
Re: why not inline all functions? ayers@incert.com (Andy Ayers) (1998-06-11) |
Re: why not inline all functions? mcdirmid@beaver.cs.washington.edu (1998-06-11) |
Re: why not inline all functions? portland@uswest.net (Thomas Niemann) (1998-06-11) |
Re: why not inline all functions? wclodius@aol.com (1998-06-11) |
Re: why not inline all functions? ian@five-d.com (1998-06-18) |
Re: why not inline all functions? hawa@celsiustech.se (Hans Walheim) (1998-06-18) |
From: | wclodius@aol.com (Wclodius) |
Newsgroups: | comp.compilers |
Date: | 11 Jun 1998 23:22:04 -0400 |
Organization: | AOL http://www.aol.com |
References: | 98-06-055 |
Keywords: | optimize, Fortran |
Andy Ayers <ayers@incert.com> wrote:
> We saw very good results on most codes -- benchmarks, certainly, but
> also many user and production codes and some parts of the HPUX
> kernel. Fortran was actually trickier than C or C++ because the formal
> parameter aliasing properties are difficult to describe accurately
> once a subroutine is inlined. The only program I remember us actually
> "flattening" completely was the spec benchmark fpppp.
I am a little surprised at this comment. I would expect that the
semantics of parameter aliasing in Fortran (no modified aliasing)
implies that the properties must be simple, otherwise the code is
illegal. Either call by reference or copy-in/copy-out semantics could
be used for legal code, or both could be tried to obtain maximum run
time, at the cost of substantial compile time.
William B. Clodius
[I suspect he meant that it was tricky carrying along the no-alias info
once the routine was expanded into in-line code. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.