Path: utzoo!attcan!uunet!husc6!think!ames!amdcad!light!bvs
From: bvs@light.uucp (Bakul Shah)
Newsgroups: comp.lang.c
Subject: Re: no noalias not negligible - a difference between C and Fortran - long
Message-ID: <1988May21.030207.25063@light.uucp>
Date: 21 May 88 10:02:05 GMT
References: <54080@sun.uucp>
Reply-To: bvs@light.UUCP (Bakul Shah)
Organization: Light Systems, Mountain View, CA
Lines: 61

In article <54080@sun.uucp> dgh%dgh@Sun.COM (David Hough) writes:
>noalias may be non-negotiable, but it may be non-negligible, as I found 
>out somewhat to my surprise this week.
...
>daxpy(n, da, dx, dy )
>        double          dx[], dy[], da;
>        int             n;
>{
>        int             i;
>
>        for (i = 0; i < n; i++) {
>                dy[i] = dy[i] + da * dx[i];
>        }
>}
...
>Anyway there is no
>portable way in draft ANSI C to say "this pointers are guaranteed
>to have no aliases".

How about adding a test before the for loop?  Something like:

#define overlap(x,y,n)    (!(x + n <= y || y + n <= x))

	if (overlap(dx, dy, n))
		return complain("overlapping arrays\n");

Now a smart compiler can figure out that dx, dy don't overlap at the
for-loop point and schedule load/stores or vectorize or whatever.  Also,
note that in a sense this is an explicit translation of fortran's
implicit noalias rule -- something you'd probably want in a similar
routine translated from fortran.

On a related topic:

Noalias had too many problems but I think a proper extension can be made
to C so that restrictions like the one above can be expressed at the
__function declaration point__.  Something like:

extern int
	daxpy(int n, double da, double dx[], double dy[])
		/* call */if (!overlap(dx, dy, n));

Here daxpy is called only if the if-expression is true; else an error is
generated.  Within the function body the condition can be assumed to be
true and that fact can be used for whatever purpose.  The if-expression
can be any expression involving constants, globals and function
parameters.

You can achieve the same effect at the point of call by using a macro
but that doesn't buy you any optimization since the compiler won't know
about it.  By expressing the same information in the language you are
telling the compiler something useful.  It can generate checking code at
every call if necessary.

The syntax is unambiguous, only one or two extra rules need to be
learned, the implementation is straight-forward and the concept is much
more powerful than noalias.  What do people think?  Of course, right now
this is just an intellectual exercise.

----
Bakul Shah <..!{ucbvax,sun}!amdcad!light!bvs>