From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8115 invoked by alias); 7 May 2005 01:15:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 7896 invoked from network); 7 May 2005 01:15:09 -0000 Received: from unknown (HELO mx2.suse.de) (195.135.220.15) by sourceware.org with SMTP; 7 May 2005 01:15:09 -0000 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id EC6D29ABF; Sat, 7 May 2005 03:15:08 +0200 (CEST) Date: Sat, 07 May 2005 03:16:00 -0000 From: Michael Matz To: Daniel Berlin Cc: Diego Novillo , James E Wilson , Jeroen Dobbelaere , gcc@gcc.gnu.org Subject: Re: restrict and char pointers In-Reply-To: <1115328931.8133.16.camel@linux.site> Message-ID: References: <325e936705050403014a64b854@mail.gmail.com> <4279309B.2070401@specifixinc.com> <325e9367050504142739d0d62d@mail.gmail.com> <1115247081.5426.144.camel@aretha.corp.specifixinc.com> <325e93670505041624262d6e2c@mail.gmail.com> <1115251703.5426.169.camel@aretha.corp.specifixinc.com> <20050505004120.GA12726@topo.toronto.redhat.com> <1115328931.8133.16.camel@linux.site> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005-05/txt/msg00343.txt.bz2 Hi, On Thu, 5 May 2005, Daniel Berlin wrote: > You can do it, but apparently restrict isn't as simple as "a and b are > both restrict pointers and therefore can never alias", because that's > not the actual definition of restrict. It says stuff about pointers > "based on" restricted objects, etc. > > Joseph Myers has shown some very weird but legal things you can do with > restrict that make it all but pointless to try to handle, at least for > the non function argument case. Disagreement here. Some of Josephs weird examples were things like: void f(int* restrict a, int * restrict b) { for (i=0; i < N; i+=2) a[i] = 2*b[i]; } int array[N]; f (&array[0], &array[1]); I.e. interleaving the pointers in a way that they both point into the same object. This is not forbidden by restrict, but it also poses no problem. The two restrict pointers still may not actually point to the same memory objects (individual array elements here), so the compiler can still trivially apply the "two restrict pointers don't alias" rule. Then there is the problem of "based on". This allows a non-restrict pointer to sometimes alias a restrict pointer. One could ignore this rule at first, for ease of implementation, and say that a unrestricted pointer can alias everything again. restricted pointers themself can only be based on other restricted pointers under very narrow circumstances, which effectively prevents them again to be aliased at their points of dereference. User actually using restrict in their programs will most probably use restrict for each pointer possible, so just handling that two restrict pointers can't alias alone would probably catch 90% of all cases. (I've actually had one user who was very confused that the vectorizer didn't do anything on his very simple two-line function, although he made all three pointer arguments be restricted). As you said the most important would probably be to handle restrict pointers in function arguments. I would add to that also those pointers which are not used in any RHS of any statement (except for being dereferenced of course). This would ensure that no other pointer is based on them. And it would allow users to write code like: void f(int* a, int *b, int n) { if (a > b+n || b > a+n) { // arrays don't overlap int * restrict ar = a; int * restrict br = b; /* Make this nonaliasing known to the compiler */ for (int i = 0; i < n; i++) ar[i] += br[i]; } else { /* They overlap, can't optimize as much */ for (int i = 0; i < n; i++) a[i] += b[i]; } } Ciao, Michael.