No subject

[Peter S. Shenkin]

Subject: Re:  noalias assertions in function prototypes

Hello.  I am an interested non-expert who has been following the non-alias 
issue from a distance for several years.  Therefore please expect (and forgive)
that my comments will fail to reflect the hard thinking that has gone on 
concerning this issue by most of the recipients of this list.  But perhaps
some of those who have given the issues deeper thought can answer my
questions.

I'll start with quotations from David Hough's note:

> ...I don't think the syntax is good, but I think the
> semantic content is at the correct level....

Concerning function prototypes for the callee:

> ... Here are two possible
> approaches:  
> 
> 	void *na_memcpy(void *s1, const void *s2, size_t n, 
> 			__noalias__(s1[0..(n-1)],s2[0..(n-1)]) ));
>  
> 	void *na_memcpy(void *s1, const void *s2, size_t n, 
> 			__noalias__(i,s1[i],s2[i]) );
> 
> __noalias__(s1[0..(n-1)],s2[0..(n-1)])
> 	means that the coder of na_memcpy and the optimizer of na_memcpy 
> may assume that s1[0]..s1[n-1] is completely disjoint from s2[0]..s2[n-1].

> __noalias__(i,s1[i],s2[i])
> 	means that the coder of na_memcpy and the optimizer of na_memcpy may
> assume that s1[i] and s2[i] are disjoint for any i...
> change s2[i] by writing to s1[i].   

My questions have mostly to do with the level of the semantics, and revolve
around the questions (1) in how much detail do we need to allow the callee 
to specify noaliasing? and (2) do we really need the caller to be able to 
over-ride the nonalias specification of the callee? I just want to present the
simplest scheme I can imagine, and perhaps those who have been thinking
hard about this for years can tell me whether/why this is inadequate.  

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.  When I say
"argument" here, of course I am also including arrays indirected through
pointers.  I think this is in essence what the Fortran standard specifies
for all arguments, but please correct me if I am wrong.  Anyway, if this 
is a sufficient degree of control by the callee, regardless of the issue of 
whether the caller should be able to override no-alias, it would seem to 
suffice to use a very simple syntax such as the following in a prototype:

void *na_memcpy(void *s1, const void *s2, size_t n, noalias(s1[],s2[]) )

The noalias statement is intended to convey the same meaning as described 
above for:

> __noalias__(i,s1[i],s2[i])

So my first question is, why is this an insufficient degree of control by
the callee, and, by implication, are the complications wrought by the
possibility of specifications such as:

> __noalias__(i,s1[expr1],s2[expr2])

really worth it, in terms of the amount of optimization that is made possible
due to the additional flexibility?

My second question is whether we really need to add something to the language to
allow a caller to override a noalias specification in the callee.  Wouldn't
the same thing be accomplished by having two similar functions, one
with a no-alias specification and one without, that the caller could
have access to?  He could then call the one he wanted.  Or, alternatively, 
one could write a dispatch function which, by means of a flag specified in 
the caller, itself called either the lower-level function that allows aliasing
of arguments or the one that doesn't.  It just strikes me that a function call
such as:

> 	(void) na_memcpy(s1, s2, n, __noalias__) ;

where __noalias__ is part of the language rather than an ordinary function
argument is a really a big change in the way the language works.  So why 
complicate things ths way if the same end can be accomplished using a
facility that the language already provides?

	-P.
************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb*************************
Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY 10027
(212)854-1418    shenkinaavogadro.barnard.columbia.edu   shenkinacunixc.BITNET
********** "I've got algorithm -- who could ask for anything more?" **********