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