Inlining and Fortran aliasing

metzger@bach.convex.com (Robert Metzger)
Tue, 28 Sep 1993 15:27:53 GMT

          From comp.compilers

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)
| List of all articles for this month |
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.
--


Post a followup to this message

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