On Fri, Mar 16, 2012 at 4:49 PM, Zdenek Dvorak <rakd...@iuuk.mff.cuni.cz> wrote:
> Hello,
>
>> On 03/16/2012 02:46 PM, Richard Guenther wrote:
>> > In the end what we want is a POINTER_PLUS_EXPR variant
>> > that does not make alias-analysis assume the result still points
>> > to within the objects the pointer pointed to before the
>> > increment/decrement.
>>
>> Hold on, is alias analysis really affected by this? Sure, we create
>> temporary pointers that point outside their base object, but we don't
>> dereference them. Anything value that ends up in a MEM_REF can only
>> point into that object again.
>
> it can be affected; by standard pointer arithmetics rules, you cannot
> create a pointer that would be outside of an object (unless you convert
> it from an integer). Thus, alias analysis may deduce that if we have
> something like
>
> int a[100];
> int *p = a + 10;
> int *q = p - i;
> *(q + 5) = 1;
> a[1] = 2;
>
> then q points inside a, and consequently q + 5 >= a + 5, hence the
> assignments do not alias. Ivopts may however produce this (in an equivalent
> form with casts to unsigned) even if i > 10.
See also the various invalid PRs that essentially do
foo (int *q)
{
int i;
int *p = &i;
long x = q - p;
*(p + x) = 1;
}
thus, cleverly encode address-space differences relative to an unrelated
object (seen in Boost, for cross-shmem pointers for example). C obviously
does not allow the "q - p" operation, and points-to analysis thinks that
p + x points to i and thus we remove the unused store to the local variable.
Another alias assumption is in offset-based analysis which assumes you
cannot have a pointer to before the object, so *(T *)(p + 1) may not
alias a global of type 'T' (because by seeing p + 1 and the access of type
T we conclude that the object pointed to is at least of size sizeof (T) + 1).
Richard.
> Zdenek
