From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4716 invoked by alias); 6 Jan 2010 15:45:14 -0000 Received: (qmail 4635 invoked by uid 22791); 6 Jan 2010 15:45:12 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-pw0-f57.google.com (HELO mail-pw0-f57.google.com) (209.85.160.57) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Jan 2010 15:45:08 +0000 Received: by pwi12 with SMTP id 12so11920092pwi.16 for ; Wed, 06 Jan 2010 07:45:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.12.3 with SMTP id p3mr17640154rvi.139.1262792706728; Wed, 06 Jan 2010 07:45:06 -0800 (PST) In-Reply-To: <20100106152559.GE20987@siel.b> References: <20100105134005.GA20987@siel.b> <84fc9c001001050546u601e565ch47783a4cb11b3eca@mail.gmail.com> <20100105150333.GC20987@siel.b> <84fc9c001001050727l648624c8y7ab055d70e98b977@mail.gmail.com> <20100105163950.GD20987@siel.b> <84fc9c001001060527kef824fdq30cac66edfb05d6f@mail.gmail.com> <20100106152559.GE20987@siel.b> Date: Wed, 06 Jan 2010 15:45:00 -0000 Message-ID: <84fc9c001001060745i3cc75b27vc011c6b15eee0eaf@mail.gmail.com> Subject: Re: adding -fnoalias ... would a patch be accepted ? From: Richard Guenther To: gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-01/txt/msg00127.txt.bz2 On Wed, Jan 6, 2010 at 4:25 PM, torbenh wrote: > On Wed, Jan 06, 2010 at 02:27:15PM +0100, Richard Guenther wrote: >> On Tue, Jan 5, 2010 at 5:39 PM, torbenh wrote: >> > On Tue, Jan 05, 2010 at 04:27:33PM +0100, Richard Guenther wrote: >> >> On Tue, Jan 5, 2010 at 4:03 PM, torbenh wrote: >> >> > On Tue, Jan 05, 2010 at 02:46:30PM +0100, Richard Guenther wrote: >> >> >> On Tue, Jan 5, 2010 at 2:40 PM, torbenh wrote: >> >> >> >> >> >> The -fno-alias-X things do not make much sense for user code (they >> >> >> have been historically used from Frontends). =A0If restrict doesn'= t work >> >> >> for you (do you have a testcase that can reproduce your issue?) >> >> >> then you probably need to wait for IPA pointer analysis to be >> >> >> fixed in GCC 4.6. >> >> > >> >> > sorry... forget the attachment :S >> >> >> >> Yes, in this case you can fix it by making ramp static. =A0Otherwise = its >> >> address may be takein in another translation unit. =A0For Fortran we >> >> have the DECL_RESTRICTED_P which we could expose to other >> >> languages via an attribute. =A0It tells that a decl is not aliased by >> >> restrict qualified pointers, so >> >> >> >> struct Ramp { >> >> =A0 =A0 float phase; >> >> =A0 =A0 inline float process() { return phase++; } >> >> } ramp __attribute__((restrict)); >> >> >> >> void fill_buffer( float * __restrict buf, size_t nframes ) >> >> { >> >> =A0 =A0 for( size_t i=3D0; i> >> =A0 =A0 =A0 =A0 buf[i] =3D ramp.process(); >> >> } >> > >> > would that also work with this stuff: >> > >> > >> > template >> > class Mixer; >> > >> > template >> > class Mixer : public Block >> > { >> > =A0 =A0private: >> > =A0 =A0 =A0 =A0T1 t1 __attribute__((restrict)); >> > =A0 =A0 =A0 =A0Mixer t2; >> > =A0 =A0public: >> > =A0 =A0 =A0 =A0inline float process() { >> > =A0 =A0 =A0 =A0 =A0 =A0return t1.process() + t2.process(); >> > =A0 =A0 =A0 =A0} >> > }; >> > >> > template >> > class Mixer : public Block >> > { >> > =A0 =A0private: >> > =A0 =A0 =A0 =A0T1 t1 __attribute__((restrict)); >> > =A0 =A0 =A0 =A0T2 t2 __attribute__((restrict)); >> > =A0 =A0public: >> > =A0 =A0 =A0 =A0inline float process() { >> > =A0 =A0 =A0 =A0 =A0 =A0return t1.process() + t2.process(); >> > =A0 =A0 =A0 =A0} >> > }; >> > >> > Mixer mix __attribute__((restrict)) > > void fill_buffer( float * __restrict buf, size_t nframes ) > { > =A0 =A0 for( size_t i=3D0; i =A0 =A0 =A0 =A0 buf[i] =3D mix.process(); > } > > there is your pointer :) ok ;) >> > >> > ? >> >> I don't see a restrict qualified pointer here. =A0Note that the >> restrict attribute would only disambiguate against those. >> Also I think you need the restrict attribute on the Mixer >> objects, not its members. > > so the attribute would promote down to all member vars of > member objects ? Yes. In fact the example above would work I guess. > >> > i still dont understand whats the problem with -fnolias, >> > as in attached patch. >> >> The patch will miscompile everything. > > point taken. > obviously reading code for a few hours without knowing enough about the > code isnt enough :) > > __attribute__((restrict)) is the better solution. > although not portable to other compilers. > > but i need this kind of functionality now, to test my concepts. > thats why i am spending a bit time on this. > > when do you plan to add this feature ? For GCC 4.6 earliest. > since you know the code, there would be no point for me to tackle > it if you do it soonish. It should be simple - just look into c-common.c, add this attribute and in the handler, for VAR_DECLs simply set DECL_RESTRICTED_P like: static tree handle_restrict_attribute (tree *node, ..., bool *no_add_attrs) { if (TREE_CODE (*node) =3D=3D VAR_DECL) DECL_RESTRICTED_P (*node) =3D true; *no_add_attrs =3D true; return NULL_TREE; } > (and you dont need to deal with dumb patches from me :) > > > speaking of dumb patches: > > would you care to comment this patch for gcc-4.4 ? > this one seems to work for simple examples. Which patch? Richard.