Xref: utzoo comp.lang.c:10359 comp.lang.fortran:687
Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!ucsd!chem.ucsd.edu!tps
From: tps@chem.ucsd.edu (Tom Stockfisch)
Newsgroups: comp.lang.c,comp.lang.fortran
Subject: Re: no noalias not negligible
Message-ID: <221@chem.ucsd.EDU>
Date: 24 May 88 19:39:13 GMT
References: <54080@sun.uucp> <11608@mimsy.UUCP> <11609@mimsy.UUCP>
Reply-To: tps@chem.ucsd.edu (Tom Stockfisch)
Organization: Chemistry Dept, UC San Diego
Lines: 24

In article <11609@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>One I forgot: inline expansion.
>daxpy is certainly short enough to write in line:
>
>The resulting expansion (either from the cleaner but nonstandard
>`inline void' versions, or the macro version) will likely not only run
>faster (no subroutine call overhead) but also be in a place where the
>optimiser can see whether there are aliasing problems.
>In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)

I don't think this will help much.  A routine which calls something as low-level
as daxpy() probably will be given pointer arguments itself rather than be
operating directly on external arrays.  Even if it isn't, most numerical
C programming uses malloc() to get arrays and matrices.  So the compiler still
will not be able to determine when pointers are aliases.

Given the awkwardness and limitations of #pragma directives, I think the
best course for vectorizing compiler writers is to experiment with their
own ideas of what noalias (and perhaps some other mechanism as well) should
mean.  People can always port code written using noalias by compiling with
"cc -Dnoalias="
-- 

|| Tom Stockfisch, UCSD Chemistry	tps@chem.ucsd.edu