[LLVMdev] Semantic of parameter attribute noalias

[matthieu at illinois.edu]

Hi,

I am trying to understand what is or what should be the correct 
semantic of the function parameter attribute noalias. 

I found:
http://zion.cs.uiuc.edu/bugs/show_bug.cgi?id=1373
and
http://www.llvm.org/docs/LangRef.html#paramattrs

from the first link:
"The semantics of 'noalias' are that they "define a new object".  
Any  pointer derived from it ("it" being the 
result of a no-alias call result, a formal parameter, or 
the result of llvm.noalias) is considered to not alias:

A. any other objects (e.g. global vars, allocas, functions, etc)
B. any other "noalias" objects
C. any other formal argument parameters or call results.

For these purposes, "pointers derived" means getelementptr and 
bitcast."

My original understanding from this was that if I have a function 
with two parameters called A and B, both being typed as "i32 *", 
and B having the noalias attribute, then any call to AA with a 
pointer derived from A and a pointer derived from B should answer 
"noalias". [Provided the AA loaded understand "noalias", which 
should be the case for BasicAA according to the bug entry.]

But my experience seems to differ from this interpretation. I only 
obtain "noalias" when both parameters have the attribute "noalias"
 instead of just B.

It seems it is only applying the rule "B" and not the rule "C".
Which let me believe that the rule "C" does not apply because 
I used a pointer derived from A instead of A itself. Which is
unfortunate.

As it seems that this attribute has been created to support C99's
"restrict" attribute, I tried to figure out what was the semantic of
"restrict". I do not have a copy of C99 close to me right now, but here
is what I found:

Indeed, all the examples I could find where using restrict 
for all pointers and where not covering the case when only one had
the restrict keyword. However, I found this:
"Rationale for International Standard—Programming Languages—C"
http://std.dkuug.dk/JTC1/SC22/WG14/www/C99RationaleV5.10.pdf
(page 82)

"Objects referenced through a restrict-qualified pointer have a special
association with that pointer. All references to that object must directly or
indirectly use the value of this pointer. In the absence of this qualifier, other
pointers can alias this object. Cacheing the value in an object designated through
a restrict-qualified pointer is safe at the beginning of the block in which the
pointer is declared, because no pre-existing aliases may also be used to reference
that object. The cached value must be restored to the object by the end of the
block, where pre-existing aliases again become available. New aliases may be
formed within the block, but these must all depend on the value of the
restrict-qualified pointer, so that they can be identified and adjusted to refer
to the cached value. For a restrict-qualified pointer at file scope, the block
is the body of main."

My own interpretation from this is that rule "C" above should be read:
C- any pointer derived from other formal argument parameters or 
call results.

as "New aliases may be formed within the block, but these must all 
depend on the value of the restrict-qualified pointer"

So here are my two questions:
- What does "restrict" actually means in this case?
- Should my interpretation of restrict being valid, does
it however means "noalias" should be updated as well? 

Matthieu Delahaye