Re: [patch] lno branch merge -- vectorizer patch #1

[Dorit Naishlos <DORIT at il dot ibm dot com>]

> That's not what the standard says - c is not a pointer, but an external
> array, i.e., it is an object.

you're right... I'll fix the code accordingly

> This isn't more strict than what the C standard requires, it's less
> strict, I think.

it's more strict than the interpretation I gave (which was wrong).


thanks,

dorit




                                                                                                                          
                      Daniel Jacobowitz                                                                                   
                      <drow@false.org>         To:       Dorit Naishlos/Haifa/IBM@IBMIL                                   
                                               cc:       Steven Bosscher <stevenb@suse.de>, gcc-patches@gcc.gnu.org, Ayal 
                      04/08/2004 18:45          Zaks/Haifa/IBM@IBMIL                                                      
                                               Subject:  Re: [patch] lno branch merge -- vectorizer patch #1              
                                                                                                                          




On Wed, Aug 04, 2004 at 06:36:39PM +0300, Dorit Naishlos wrote:
>
> > And the "C sense" (C semantics) is that two restrict-qualified pointers
> > cannot be aliases of the same object.  But a restricted pointer and a
> > non-restricted pointer can still be aliases.
>
> This is not what I understand from the C standard; Example 1 in section
> 6.7.3.1 refers to the case in which you have two pointers that are
> restricted, a and b, and one pointer, c, that isn't.  It says the
> following:
>
> "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".

That's not what the standard says - c is not a pointer, but an external
array, i.e., it is an object.

> I actually check something much stricter in the function below - I don't
> check that the object is modified _anywhere_ in the program, but that the
> object is modified by the restricted pointer in the data-reference in
> question. To my understanding, this guarantees that no other pointer can
be
> used to access the same object in the loop. Is this a correct
> interpretation?

This isn't more strict than what the C standard requires, it's less
strict, I think.

You wrote:
> > +   /* An insn writing through a restricted pointer is "independent" of
any
> > +      insn reading or writing through a different pointer, in the same
> > +      block/scope.
> > +    */

But actually this isn't true.  This is legitimate:
void func (int * restrict a, int * b)
{
  a[0] = b[0];
  a[1] = b[1];
}

  func (&c[3], &c[2]);

The write of a[0] (through a restricted pointer) and read of b[1]
(through a non-restricted pointer) conflict.

Yet another reason why restrict is a pain.

--
Daniel Jacobowitz