Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: More on noalias
Message-ID: <10129@mimsy.UUCP>
Date: 11 Jan 88 17:05:27 GMT
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 84
Summary: If we must shoot ourselves in the foot, let us make it a clean wound.

By now I imagine everyone knows that I am opposed to noalias.  This
is not yet another argument against `noalias' *per se*; rather, it
is an argument for a different mechanism---one that is cleaner (I
claim) and more useful.

First, a side point.  While I have not seen the proposed semantics
for the keyword `noalias', I suspect that it does not in fact mean
that some variable is not aliased.  Aliasing, after all, is not a
property of a single variable; aliasing occurs only between some
group of variables.  `*p' may alias `j' without aliasing `v', for
instance.  So the word `noalias' itself is wrong: it probably means
`this variable is not aliased with any other variable that is in
fact used in the same or any inner scope'.  (In other words, called
procedures may alias the variable, so long as the alias is gone,
or remains unused, by the time that procedure returns.)

But let us take for granted that some mechanism like `noalias' is
worthwhile---that if we can give the compiler a hint, it may be able
to produce much faster or smaller code.  What, then, is wrong with
`noalias'?  It is, I claim, the wrong hint---if not always, at least
often enough.  Among other things, it is hardly general.

First, let me construct an example in which aliasing is relatively
hard to detect.  How about this:

	void
	vector_add /* maybe */ (int *a, int i, int j, int k, int n)
	{

		for (; --n >= 0; i++, j++, k++)
			a[i] = a[j] + a[k];
	}

This can use a vector add iff i != j and i != k (on some hypothetical
machine).  Hence the compiler wants to know whether this will be
true.  By declaring `int *noalias a' or `noalias int *a' (whichever
it is), we could say that.  But we could say that much better this
way:

	void
	vector_add /* really */ (int *a, int i, int j, int k, int n)
	{

		for (; --n >= 0; i++, j++, k++) {
			compiler_hint(alias: i != j, alias: i != k);
			a[i] = a[j] + a[k];
		}
	}

Not only are we then saying what we mean, we have a condition we
can test!

		if (i == j || i == k)
			panic("vector_add called illegally");
		for (...) etc.

Of course, by putting in the `panic' and adding

	compiler_hint(flow: dead panic());
	void panic(char *s);

we could leave out the `alias:' hint too.  But if we have only
`noalias', we cannot hint to flow analysis that panic() never
returns.

There is a miniature raging debate in comp.arch going on at this
very minute over the Fortran `frequency' statement.  If there exist
machines on which the proper `frequency' statement might make some
function run ten times faster, but all we have in C is `noalias',
you may have to write that function in assembly.  Too bad you
cannot say

	compiler_hint(flow: probability i < 0: .001);

No matter what it is the compiler wants to know, if you have a
general mechanism, you can tell it.  With `noalias' you can only
tell it about aliasing.  To reword the `summary' line above, if we
must have compiler hints, let us at least make them general.  ANS
X3J11 could specify the form which some compiler hints should take,
specifically those involving aliasing.  (The form I used was made
up on the spur of the moment, and could stand improvement.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 ????)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris