Path: utzoo!mnetor!uunet!husc6!purdue!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: More on noalias
Message-ID: <10155@mimsy.UUCP>
Date: 13 Jan 88 02:06:27 GMT
References: <10129@mimsy.UUCP> <3433@megaron.arizona.edu>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 36

In article <3433@megaron.arizona.edu> mike@arizona.edu (Mike Coffin) writes:
>I wish I knew for sure what noalias meant.

So do I---it is hard to argue against something when no one will say
exactly what that something is :-) . . . .

>In any case, you can already (in good old K&R C) write the above
>function in a way that allows vector add:

Actually, that was nearly half the point.

> 	void
> 	vector_add /* maybe */ (int *a, int i, int j, int k, int n)
> 	{
> 		if (i==j || i==k) return;
>
>		/* now the compiler can infer that i!=j and i!=k */
> 		for (; --n >= 0; i++, j++, k++)
> 			a[i] = a[j] + a[k];
> 	}

(`Return' may be the wrong thing to do; but ignore that for now.)

I believe it is far better to *ensure* that some optimisation is
safe than simply to *declare* it so (as `noalias' appears to do).
But I am willing to concede that there may be cases in which this
is infeasible, and compiler hints will be used.  In such cases, it
would be best, I say, to put the hint as close as possible to the
affected code, and to make the hint as direct as possible, so that
it hints no more than is needed.

Or, mixing metaphores again, writing `noalias' is like using a
bandsaw to cut a keyhole.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris