[Bug c/48885] missed optimization with restrict qualifier?

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48885

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Paulo J. Matos from comment #3)
> My understanding is that for restrict optimization to take effect, variable
> a has also to be restrict. Otherwise in the first assignment *a = *v;, a
> could point to the same memory as v

No, the standard is quite clear that restrict is only needed on one variable to
ensure it doesn't alias the other.

"During each execution of B, let L be any lvalue that has &L based on P. If L
is used to access the value of the object X that it designates, and X is also
modified (by any means), then the following requirements apply: T shall not be
const-qualified. Every other lvalue used to access the value of X shall also
have its address based on P"

v points to X
P is v
L is *v
a is not based on v (if I write v=0, that doesn't change the value of the
pointer a), so the lvalue *a cannot be used to access X.

There is even an example where restrict is not specified on all variables:

"EXAMPLE 1 The file scope declarations
int * restrict a;
int * restrict b;
extern int c[];
assert that if an object is accessed using one of a, b, or c, and that object
is modified anywhere in the program, then it is never accessed using either of
the other two."



A separate remark, for the case with no "restrict" at all:
- if *a and *v are disjoint, we don't need the second load;
- if a == v, we don't need the second load either;
- the only case where we could need a reload is if *a and *v partially overlap,
I don't know if that's ever legal.