Xref: utzoo comp.lang.c:10374 comp.lang.fortran:688
Path: utzoo!attcan!uunet!husc6!mailrus!ames!pasteur!ucbvax!decwrl!labrea!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c,comp.lang.fortran
Subject: Re: no noalias not negligible
Message-ID: <1015@cresswell.quintus.UUCP>
Date: 25 May 88 02:55:44 GMT
References: <54080@sun.uucp> <11608@mimsy.UUCP> <11609@mimsy.UUCP> <221@chem.ucsd.EDU>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 31

In article <221@chem.ucsd.EDU>, tps@chem.ucsd.edu (Tom Stockfisch) writes:
> 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="

#pragma is pretty open-ended, so I don't see why it should be awkward.
Apart from the "no change to the meaning of the program" bit which might
as well be thrown away, #pragma seems to me a much better means than
something like noalias.

Why?  Well, let's take the daxpy() example.  The property the compiler
needs is NOT that dx has no aliases or that dy has no aliases, but that
dx and dy do not overlap.  More generally a declaration
	#pragma disjoint(x, ..., z)
might tell a compiler "assume that anything accessed via 'x' is
distinct from anything accessed via ..., 'z'" and so on.

I might well have a program with four pointers
	p, q, r, s
where	#pragma disjoint(p, q)	/* or _disjoint (p,q), (r,s); */
	#pragma disjoint(r, s)	/* or whatever */
but p and r might be potentially aliased and so might q and s.
That shouldn't inhibit optimisation in regions where only p and q
appear or where only r and s appear.

This is not a proposal for a replacement for 'noalias'.  I merely point
out that since aliasing is a property of _sets_ of variables, trying to
hack it with declarations about _single_ variables doesn't seem like a
good approach.