On Aug 21, 2007, at 11:10 PM, Duncan Sands wrote:> Hi Christopher, > >> In C/C++ a restrict pointer is also assumed not to alias any other >> parameters, global values or local value. However the compiler must >> not assume that pointers "based on" a restrict pointer do not alias. > > does "based on" mean something like: copies of the pointer made in the > function body?To be precise (brackets mine): In what follows, a pointer expression E is said to be based on object P [a pointer] if (at some sequence point in the execution of B [the enclosing block] prior to the evaluation of E) modifying P to point to a copy of the array object into which it formerly pointed would change the value of E. Note that ‘‘based’’ is defined only for expressions with pointer types. This is from http://www.open-std.org/jtc1/sc22/wg14/www/docs/ n1124.pdf Sec 6.7.3.1 para 3>> Your example strikes me as contradictory to your description of Ada >> aliasing rules above. If A and B were in fact copies of an object >> then in your first example x would always be 0, no matter which order >> the reads and writes are performed. Thus if permuting those memory >> operations is safe when copies are passed then that same transform >> is, by your definition, allowed when the same array is passed as both >> parameters by reference. >> >> I can't reconcile your statement that in Ada array parameters can be >> assumed to not alias, but that that the compiler must be careful to >> limit the transforms it applies in the case that they do alias. >> >> Is there a reference that you can point to in the Ada spec that >> describes this concretely? > > Sure, check out > http://www.adaic.com/standards/05aarm/html/AA-6-2.html > Some types, like array types, are neither by-copy types nor by- > reference > types. The candidates I have in mind for noalias are formal > parameters > of such a type. The parameter passing mechanism used for the > parameter > is then not specified (6.2.11). As explained in 6.2.12, if you write > to the passed object via some other parameter or a global variable, > then read via this parameter, it is undefined as to whether you read > the new value or some old value (or raise an exception). The rest of > section 6.2 discusses this rule, see especially 6.2.12.j.I'll take a look as time permits. -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070822/1585dcca/attachment.html>
On Aug 22, 2007, at 1:19 PM, Duncan Sands wrote:> Hi Christopher, > >>>> In C/C++ a restrict pointer is also assumed not to alias any other >>>> parameters, global values or local value. However the compiler must >>>> not assume that pointers "based on" a restrict pointer do not >>>> alias. >>> >>> does "based on" mean something like: copies of the pointer made >>> in the >>> function body? >> >> To be precise (brackets mine): >> >> In what follows, a pointer expression E is said to be based on object >> P [a pointer] if (at some >> sequence point in the execution of B [the enclosing block] prior to >> the evaluation of E) modifying P to point to >> a copy of the array object into which it formerly pointed would >> change the value of E. >> Note that ‘‘based’’ is defined only for expressions with pointer >> types. >> >> This is from http://www.open-std.org/jtc1/sc22/wg14/www/docs/ >> n1124.pdf Sec 6.7.3.1 para 3 > > suppose A and B are array pointers, and are in fact equal. Consider > the code sequences > > (i) > x = A[0] (a) > B[0] = 1 (b) > > and > > (ii) > B[0] = 1 (b) > x = A[0] (a) > > If I understand right, (i)(b) is not based on A, either because it > has no value (not sure what "the value of E" means) or because > changing > A to point to a copy would make no difference because (i)(a) is only a > read. Also (i)(a) is not based on B because this is the first > instruction. > On the other hand (ii)(a) is based on B because the value of x > is 1, but would be something else if B was changed to point to a copy. > > Does this mean that if B is a restricted pointer, then the lines > can be > swapped in (i). That if A is a restricted pointer then the lines > can be > swapped in (i) and (ii)? > > This sounds very similar to the Ada setup, though somehow "dual" to > it.If A and B are function arguments then there is no "based on" relationship between pointer expressions A+0 and B+0. This is because changing one of the pointers, A for example, to point to a copy of the object it points to would change the value of the pointer expression A+0, but not the expression B+0. This means that if either A or B is a restrict pointer then the expressions in both (i) and (ii) may be executed in any order. This also means that if the function were called with A == B and either A or B is defined as restrict then the result would be undefined behavior. -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070822/77d031a0/attachment.html>