llvm dev - Jan 2015 - [LLVMdev] Can we assume const parameter and to-be-modified parameter do not alias?

Hi, 

This question is raised from the following example:
 
int foo (const int a[], int b[])
{
     ...
     b[i] = …
     …
}

Basically a[] is defined as read-only while b[] will be explicitly modified in
the function.  At the first glance, they can not be alias but  it seems that we
can not figure out the alias info between them now which prevent us from doing
some optimizations.   Here is the quote from:

c99 rationale, v5.10, p. 77

const is specified in such a way that an implementation is at liberty to put
const objects in read-only storage, and is encouraged to diagnose obvious
attempts to modify them, but is not required to track down all the subtle ways
that such checking can be subverted.

Our understanding is that it is user’s responsibility to guarantee that const
array will not be touched in any way and if not the behavior is undefined and in
this case it is safe to assume that they are not alias?

Hi Yi,

On 9 January 2015 at 14:21, yi_jiang <yjiang at apple.com>
wrote:
> Our understanding is that it is user’s responsibility to guarantee that
const array will not be touched in any way and if not the behavior is undefined
and in this case it is safe to assume that they are not alias?
I wouldn't have said so. Const doesn't guarantee an object won't be
modified via a different route in C or C++ (which is one of the
reasons it's often criticised as being a bit too weak). I think const
gives you two things:

+ If you attempt to modify an object *using a const-qualified type*
the compiler must diagnose a problem (it's not a modifiable lvalue in
6.5.16)
+ An underlying object declared const cannot be modified by casting
that away (it's undefined behaviour).

It would be perfectly valid to form (say) a const pointer to a
non-const object and pass that around though; and also perfectly valid
to either pass another (non-const) pointer to that object around in
parallel or even to cast away that constness and modify the object.

Cheers.

Tim.

I don't think this statement is correct:
> At the first glance, they can not be alias but  it seems that we can not
figure out the alias info between them now which prevent us from doing some
optimizations.
As an example, take memcpy, which from the C99 standard is defined as:

void * memmove(void * s1, const void *s2, size_t n);

It is perfectly legal to pass to memmove parameters such that an access through
s1 can overlap an access through s2.  That is why the standard goes to the
trouble of specifying the semantics when the two areas can overlap.

It is perfectly legal to do make a call to memmove such as:

t = memmove(&a[0], &a[2], 200);

But, the advantage of the const specifier is that the caller can tell that
memmove doesn't modify the object pointed to by the second parameter,
provided that the
call cannot modify that through the non-const first parameter.

Kevin Smith


-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of yi_jiang
Sent: Friday, January 09, 2015 2:22 PM
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] Can we assume const parameter and to-be-modified parameter do
not alias?

Hi, 

This question is raised from the following example:
 
int foo (const int a[], int b[])
{
     ...
     b[i] = ...
     ...
}

Basically a[] is defined as read-only while b[] will be explicitly modified in
the function.  At the first glance, they can not be alias but  it seems that we
can not figure out the alias info between them now which prevent us from doing
some optimizations.   Here is the quote from:

c99 rationale, v5.10, p. 77

const is specified in such a way that an implementation is at liberty to put
const objects in read-only storage, and is encouraged to diagnose obvious
attempts to modify them, but is not required to track down all the subtle ways
that such checking can be subverted.

Our understanding is that it is user's responsibility to guarantee that
const array will not be touched in any way and if not the behavior is undefined
and in this case it is safe to assume that they are not alias?
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Tim & Smith,

Thank you guys. I was confused by the array parameter. It is actually pretty
much the pointer parameter and I agree with your explanation.
On Jan 9, 2015, at 3:09 PM, Smith, Kevin B <kevin.b.smith at intel.com>
wrote:
> I don't think this statement is correct:
> 
>> At the first glance, they can not be alias but  it seems that we can
not figure out the alias info between them now which prevent us from doing some
optimizations.
> 
> As an example, take memcpy, which from the C99 standard is defined as:
> 
> void * memmove(void * s1, const void *s2, size_t n);
> 
> It is perfectly legal to pass to memmove parameters such that an access
through s1 can overlap an access through s2.  That is why the standard goes to
the
> trouble of specifying the semantics when the two areas can overlap.
> 
> It is perfectly legal to do make a call to memmove such as:
> 
> t = memmove(&a[0], &a[2], 200);
> 
> But, the advantage of the const specifier is that the caller can tell that
memmove doesn't modify the object pointed to by the second parameter,
provided that the
> call cannot modify that through the non-const first parameter.
> 
> Kevin Smith
> 
> 
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu] On Behalf Of yi_jiang
> Sent: Friday, January 09, 2015 2:22 PM
> To: llvmdev at cs.uiuc.edu
> Subject: [LLVMdev] Can we assume const parameter and to-be-modified
parameter do not alias?
> 
> Hi, 
> 
> This question is raised from the following example:
> 
> int foo (const int a[], int b[])
> {
>     ...
>     b[i] = ...
>     ...
> }
> 
> Basically a[] is defined as read-only while b[] will be explicitly modified
in the function.  At the first glance, they can not be alias but  it seems that
we can not figure out the alias info between them now which prevent us from
doing some optimizations.   Here is the quote from:
> 
> c99 rationale, v5.10, p. 77
> 
> const is specified in such a way that an implementation is at liberty to
put const objects in read-only storage, and is encouraged to diagnose obvious
attempts to modify them, but is not required to track down all the subtle ways
that such checking can be subverted.
> 
> Our understanding is that it is user's responsibility to guarantee that
const array will not be touched in any way and if not the behavior is undefined
and in this case it is safe to assume that they are not alias?
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev