|Re: Loop Optimizations and Gotos firstname.lastname@example.org (1995-11-22)|
|alias analysis (was Loop Optimizations and Gotos) bwilson@shasta.Stanford.EDU (Bob Wilson) (1995-11-28)|
|Re: alias analysis (was Loop Optimizations and Gotos) email@example.com (1995-11-29)|
|alias analysis (was Loop Optimizations and Gotos) firstname.lastname@example.org (Dave Lloyd) (1995-12-09)|
|Re: alias analysis (was Loop Optimizations and Gotos) email@example.com (1995-12-12)|
|Re: alias analysis (was Loop Optimizations and Gotos) firstname.lastname@example.org (1995-12-17)|
|From:||email@example.com (Cliff Click)|
|Keywords:||C, Fortran, optimize|
|Date:||Wed, 29 Nov 1995 13:45:26 GMT|
Bob Wilson <bwilson@shasta.Stanford.EDU> writes:
> firstname.lastname@example.org (Cliff Click) wrote:
> > There's no general way to figure out the Fortran no-alias assertion in
> > C code (lots of IPA can get you part of the way there, but not all the
> > way). Lack of this assertion can hurt some dependence analysis, with
> > the results outlined above.
> For Fortran-style programs written in C, interprocedural pointer
> analysis provides very accurate information and only requires a
> small amount of extra compile time. (The situation is less clear
> for non-numeric programs with lots of recursive data structures,
> but even there it appears that pointer analysis can be made to
> work quite well.)
Ok, I'll retract:
There's no _general_ way to figure out the Fortran no-alias
assertion in C code, but lots of IPA can get you MOST of the
way there, but not all the way.
The Moto compiler does some IPA alias analysis on C right now. More
is certainly coming. We don't yet use it to do loop transformations,
but it does help scheduling and value numbering.
So how about my other claim, industrial compiler writers? Is IP alias
analysis for C common? Is it then used to do loop transformations?
Cliff Click Compiler Researcher & Designer
RISC Software, Motorola PowerPC Compilers
email@example.com (512) 891-7240
Return to the
Search the comp.compilers archives again.