[LLVMdev] c const

[Christopher Lamb]

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>