matthieu at illinois.edu
2008-Aug-22 16:45 UTC
[LLVMdev] 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
On Fri, Aug 22, 2008 at 9:45 AM, <matthieu at illinois.edu> wrote:> 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
Maybe Matching Threads
- noalias parameter attribute not currently exploited by alias analysis?
- noalias parameter attribute not currently exploited by alias analysis?
- [LLVMdev] Upcoming Changes/Additions to Scoped-NoAlias metadata
- [LLVMdev] Upcoming Changes/Additions to Scoped-NoAlias metadata
- Potential issue with noalias @malloc and @realloc