This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> 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".

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?

(also see http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00249.html).

dorit



                                                                                                                           
                      Steven Bosscher                                                                                      
                      <stevenb@suse.de>        To:       Dorit Naishlos/Haifa/IBM@IBMIL, gcc-patches@gcc.gnu.org           
                                               cc:                                                                         
                      03/08/2004 18:31         Subject:  Re: [patch] lno branch merge -- vectorizer patch #1               
                                                                                                                           




On Thursday 22 July 2004 18:26, Dorit Naishlos 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.
> +    */
> +   if ((TREE_CODE (ta) == POINTER_TYPE && TYPE_RESTRICT (ta)
> +        && !DR_IS_READ(a))
> +       || (TREE_CODE (tb) == POINTER_TYPE && TYPE_RESTRICT (tb)
> +            && !DR_IS_READ(b)))
> +     {
> +       *differ_p = true;
> +       return true;
> +     }

This is not the semantics of 'restrict' the way I remember it (but of
course I may be wrong ;-) In tree.h the comment for TYPE_RESTRICT states:

    /* If nonzero, this type is `restrict'-qualified, in the C sense of
       the term.  */

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.  So iiuc the above check
should set differ_p to false unless ta and tb are both restrict qualified
(and they are nor the same object, but that's checked earlier).

Gr.
Steven






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]