Path: utzoo!mnetor!uunet!husc6!hao!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: why not noalias
Message-ID: <9899@mimsy.UUCP>
Date: 20 Dec 87 04:10:39 GMT
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 37

Various compiler people will no doubt argue in favour of `noalias'.
I shall argue against it, for the same reason that I would argue
against `register' in any new language proposal:  It is something
for the compiler to decide.

Now, it is true that perfect alias detection is hard:

	ref int x;
	program p { int v; alias(&v); ... /* code using x */ };

	prodecure alias(ref int v) {
		/*
		 * If this program makes the alias, do not make the alias;
		 * otherwise, make the alias.
		 */
		if (!hasalias("program p, procedure call alias(&v)"))
			x = v;
	};

but so are a lot of other things that compilers do now with
approximate algorithms.  In many cases (and I will go so far as to
claim `in most cases') the simple test `does procedure P or any of
its child procedures even possibly create an alias for variable V'
suffices.  More precise determination using flow analysis is of
course possible (but, I think, unnecessary).  The `simple test'
decision is relatively easy to make at link time.  Most (if not
all) serious optimising compilers will keep intermediate code, not
machine instructions, around until link time, to do interprocedural
register allocation, procedure hoisting, and all those other good
things that a few compilers do now.

To put it simply, I think the burden of discovering aliasing
should be only on the compiler.  Hints from programmers are
all right ... as long as they are *correct*!
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris