Re: Unreviewed patches (since February/March)

[Daniel Berlin <dberlin at dberlin dot org>]

On Wed, 11 Sep 2002, Richard Henderson wrote:

> On Mon, Sep 02, 2002 at 01:51:58PM -0700, Dan Nicolaescu wrote:
> > char* restrict should not be put in alias set 0
> 
> The semantics of restrict are that, on entry to the block
> the pointer is the only reference to the object.  Nothing
> is said about what happens after the block is entered; it
> is up to the compiler to track the data flow accordingly.
No.
This is incorrect.
Please read 6.7.3.1 again.
It says:

   6.7.3.1 Formal definition of restrict

    1. Let D be a declaration of an ordinary identifier that provides a means of designating an object P as a
       restrict-qualified pointer to type T.
    2. If D appears inside a block and does not have storage class extern, let B denote the block. If D appears in the list
       of parameter declarations of a function definition, let B denote the associated block. Otherwise, let B denote the
       block of main (or the block of whatever function is called at program startup in a freestanding environment).
    3. In what follows, a pointer expression E is said to be based on object P if (at some sequence point in the execution of
       B 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.
    4. 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. Every access
       that modifies X shall be considered also to modify P, for the purposes of this subclause. If P is assigned the value
       of a pointer expression E that is based on another restricted pointer object P2, associated with block B2, then either
       the execution of B2 shall begin before the execution of B, or the execution of B2 shall end prior to the assignment.
       If these requirements are not met, then the behavior is undefined.
    5. Here an execution of B means that portion of the execution of the program that would correspond to the lifetime of an
       object with scalar type and automatic storage duration associated with B.
    6. A translator is free to ignore any or all aliasing implications of uses of restrict.


Note nothing about "entrance".
It tells you what the behavior is like *during* the block in which it's 
declared.

> conflict.
> 
> We do this so that we properly compile code like
> 
> 	void foo (int * restrict a, int * restrict b, bool p)
> 	{
> 	  int * c = (p ? a : b);
> 
> At this point, C does in fact conflict with both A and B.

No, it doesn't.
It conflicts with exactly one of them, but we might not know which one.
However, if you could determine p at compile time (through this routine 
being inlined and p being given some definite value, or whatever ), then 
you would, for a certainty, know which one, and could optimize based on it.

In short: We know that A and B don't conflict with each other, 
and c doesn't conflict with one of them, depending on the value of p.

In fact, you could write an optimization that copied the rest of the 
function into two arms of an if (p) block, and in each one, you'd be able 
to optimize appropriately.