Semantic of parameter attribute noalias

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

So here are my two questions:
- What does "restrict" actually means in this case?

If I'm reading the standard correctly, "restrict" on a parameter
roughly means that if the current function, or any function it calls,
accesses memory through an pointer whose value depends on the value of
the parameter, all accesses must depend on the value of that pointer.

- Should my interpretation of restrict being valid, does
it however means "noalias" should be updated as well?

The documentation is a bit unclear, but I'm pretty sure the definition
is supposed to guarantee precisely the following: if P is a noalias
parameter, and Q is a pointer not derived from P, between the entry to
the function and the return from the function, alias(P,Q) is false.
What BasicAA implements fits this definition; I think the fact that
it's missing the case of a noalias argument and a non-noalias argument
is just an accident.

That said, I'm not sure if this is precisely equivalent to the C
version; the C definition of restrict means that it only kicks in if
there's a load from a restrict pointer, and the definition of noalias
and the BasicAA implementation make me think that it applies even if
there aren't any memory operations involved.

-Eli