alias analysis (was Loop Optimizations and Gotos)

Dave Lloyd <>
9 Dec 1995 19:37:12 -0500

          From comp.compilers

Related articles
Re: Loop Optimizations and Gotos (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) (1995-11-29)
alias analysis (was Loop Optimizations and Gotos) (Dave Lloyd) (1995-12-09)
Re: alias analysis (was Loop Optimizations and Gotos) (1995-12-12)
Re: alias analysis (was Loop Optimizations and Gotos) (1995-12-17)
| List of all articles for this month |

From: Dave Lloyd <>
Newsgroups: comp.compilers
Date: 9 Dec 1995 19:37:12 -0500
Organization: Compilers Central
References: 95-11-198 95-11-228
Keywords: C, Fortran, optimize (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.

Well it seems to me that C could easily acquire a new "storage-class",
say "independent" (after the HPF equivalent) which when applied to a
pointer means "the storage at the end of this pointer is only
accessible via this pointer within this scope". The language is
already full of such things - "const", "inline", "register" - and as
compilers get better its use may decline as "register" has and as
"inline" undoubtedly will. Thus the Fortran-style procedure in C
would be written:
                void fsub (real independent *x)

However, what seems to be forgotten by the C compiler community
longing for Fortran performance is that the no-alias rules are equally
hard to check and often forgotten by Fortran programmers trying to
minimise storage so a compiler which optimises on this basis can break
apparently working code in very obscure ways. Personally I dislike
language rules which can't readily be checked. Explicit use of
"independent" at least alerts the programmer to a possible problem.

Besides, while the no-alias rules help a lot with F77-style code, the
array constructs of F90 allow more aggressive optimisation with
limited information. Perhaps more emphasis should be given to
providing C with a proper array type and some operations to go with
it. While you're at it, formal list types over which the compiler has
control of representation would be good as well. Bottom line:
language constructs which imply work over many data-items allow
compilers greater latitude in high-performance implementation,
critically so in parallel applications.

Dave Lloyd Email:
Oxford and Cambridge Compilers Ltd Phone: (44) 1223 572074
55 Brampton Rd, Cambridge CB1 3HJ, UK

Post a followup to this message

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