Related articles |
---|
When to do inline expansion jhall@whale.WPI.EDU (1993-09-14) |
Re: When to do inline expansion cliffc@rice.edu (1993-09-22) |
Inlining and Fortran aliasing metzger@bach.convex.com (1993-09-28) |
Newsgroups: | comp.compilers |
From: | metzger@bach.convex.com (Robert Metzger) |
Keywords: | optimize |
Organization: | Compilers Central |
References: | 93-09-063 93-09-109 |
Date: | Tue, 28 Sep 1993 15:27:53 GMT |
> Fortran subroutine calls have *extra* semantic information: all arrays
> passed are guarenteed not to be aliased. This let the MIPS compiler
> get the kernal of (DAXPY? some linpack kernal) right. When inlined the
> same code ran much slower because the compiler inserted stalls under
> the assumption that the arrays might be aliased.
>
>[Loss of aliasing info is the best known ``gotcha'' in Fortran (and, probably
>any) in-lining. Does anyone know of real compilers where they correctly
>track the unaliasable variables in inlined Fortran? -John]
The Convex Application Compiler (Fortran and C compiler with
interprocedural optimization) performs extensive inlining of both Fortran
and C applications. It's been commercially available for 2.5 years. I
assume that qualifies for "real".
The inlining algorithm knows that it should preserve Fortran's "assume
arguments aren't dangerous aliases" semantics, and passes along the
independence of arguments info where appropriate. For example:
real a(100)
parameter(i=1,j=51)
call foo(a(i),a(j),50)
end
subroutine foo(c,d,n)
real c(n), d(n)
do i=1,n
c(i) = c(i) + d(i-1)
enddo
end
P.S. Just so there's no confusion, the Convex compiler mentioned in the
Rice papers is the procedural Fortran compiler, not the Application
Compiler. The APC was not available when Mary et al did their studies.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.