noalias assertions

Thomas M. Breuel uunet!ai.mit.edu!tmb
Mon Oct 21 20:43:53 PDT 1991


|> On question (1), suppose that the callee needs only to assert that in any 
|> invocation of the function, no portion of some particular argument that is
|> assigned to can overlap any portion of some other argument. [*]

Depending on your hardware, I think there are three different constructs
that are useful:

 * readcache pointer[range]: the compiler may generate code to cache reads, 
   but not writes, in the specified range.

 * writecache pointer[range]: the compiler may generate code to cache reads 
   and writes in the specified range, but it may not write back locations
   that were not modified in the cache. (If the same location has been modified
   in two caches, the behavior is undefined.)

 * blockcache pointer[range]: the compiler may generate code to cache the
   complete range of data and copy it back at any later point, modified or
   unmodified.

(All caching ends when the block containing the assertions exits.)

"readcache" and "writecache" can both be used in the case described
above at [*]. "blockcache" is probably the most useful constraint for
a lot of hardware, though.

With this, a definition for memcpy might look like:

	void memcpy(char *dest,char *source,int n;
		    blockcacblockcache dest[0..n],source[0..n])
	{
	}

A more detailed declaration might be:

	void complicated(float *a,float *b,int n,int m;
		         blockcache a[0..n/2],b[0..10],b[n/2..m])
	{
	}

I think "blockcache", which I believe is essentially what
the current proposal says, is by far the most common case.
The other two assertions may also be useful on occasion (in
particular, where assignments and reads are interleaved in
the same data structure).

I think allowing arbitrarily complicated specifications of 
what aliases what are not very useful--they are too far removed
from the capabilities of the machine, and they add too much
syntactic hair. Being able to specify a collection of ranges
should be enough.

					Thomas.



More information about the Numeric-interest mailing list