From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13725 invoked by alias); 3 Jun 2009 15:35:07 -0000 Received: (qmail 13693 invoked by uid 22791); 3 Jun 2009 15:35:03 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_20,J_CHICKENPOX_33 X-Spam-Check-By: sourceware.org Received: from mms1.broadcom.com (HELO mms1.broadcom.com) (216.31.210.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Jun 2009 15:34:57 +0000 Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 03 Jun 2009 08:34:45 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Wed, 3 Jun 2009 08:34:45 -0700 From: "Bingfeng Mei" To: "Richard Guenther" cc: "gcc@gcc.gnu.org" Date: Wed, 03 Jun 2009 15:35:00 -0000 Subject: RE: Restrict keyword doesn't work correctly in GCC 4.4 Message-ID: <7FB04A5C213E9943A72EE127DB74F0AD814FF13048@SJEXCHCCR02.corp.ad.broadcom.com> References: <7FB04A5C213E9943A72EE127DB74F0AD814FD670B3@SJEXCHCCR02.corp.ad.broadcom.com> <84fc9c000906030353q4d873627v72164ad4cb6afc54@mail.gmail.com> <7FB04A5C213E9943A72EE127DB74F0AD814FD670BC@SJEXCHCCR02.corp.ad.broadcom.com> <84fc9c000906030709n28d63faaub982696153e98782@mail.gmail.com> In-Reply-To: <84fc9c000906030709n28d63faaub982696153e98782@mail.gmail.com> MIME-Version: 1.0 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: 2009-06/txt/msg00045.txt.bz2 Richard, Thanks. I tried your patch and the -fno-tree-ter, and none works. The probl= em is that=20 decl =3D find_base_decl (TREE_OPERAND (inner, 0)); <--- Cannot find= the base declaration, so decl =3D 0 if (decl <-- won't be checked && POINTER_TYPE_P (TREE_TYPE (decl)) && TYPE_RESTRICT (TREE_TYPE (decl))) The TREE_OPERAND (inner, 0) is: unit size align 32 symtab 0 alias set 2 canonical type 0xf7f122f4 precisi= on 32 min max pointer_to_this > sizes-gimplified public unsigned restrict SI size unit size align 32 symtab 0 alias set -1 canonical type 0xf7fa6870> =20=20=20 arg 0 unit size align 32 symtab 0 alias set -1 canonical type 0xf7f12438 precis= ion 32 min max > =20=20=20=20=20=20=20 arg 0 used unsigned ignored SI file tst.c line 1 col 6 size unit size align 32 context (reg:SI 104 [ D.1768 ])> arg 1 tst.c:7:5> tst.c:7:5> I added the following code. It seems to work for my example and others. Not= sure potential hazard with it. ... else if(!decl && POINTER_TYPE_P (TREE_TYPE (TREE_OPERAND(inner, 0))) && TYPE_RESTRICT (TREE_TYPE (TREE_OPERAND(inner, 0)))) { return new_alias_set (); } ....=20=20=20=20=20=20=20=20=20 Bingfeng > -----Original Message----- > From: Richard Guenther [mailto:richard.guenther@gmail.com]=20 > Sent: 03 June 2009 15:10 > To: Bingfeng Mei > Cc: gcc@gcc.gnu.org > Subject: Re: Restrict keyword doesn't work correctly in GCC 4.4 >=20 > On Wed, Jun 3, 2009 at 1:02 PM, Bingfeng Mei=20 > wrote: > > Richard, > > Yes, my original code does have restrict qualified decl: > > > > =A0void foo(int byte, char *a, char *b){ > > =A0int * restrict dest =3D (int *)a; > > =A0int * restrict src =3D (int *)b; > > > > =A0for(int i =3D 0; i < byte/8; i++){ > > =A0 =A0*dest++ =3D *src++; > > =A0} > > } > > > > > > The code I shown is produced by tree level compilation. > > > > =A0*(int * restrict) (D.1934 + 4) =3D *(int * restrict) (D.1936 + 4); > > =A0*(int * restrict) (D.1934 + 8) =3D *(int * restrict) (D.1936 + 8); > > =A0*(int * restrict) (D.1934 + 12) =3D *(int * restrict) (D.1936 + 12); > > =A0*(int * restrict) (D.1934 + 16) =3D *(int * restrict) (D.1936 + 16); > > =A0*(int * restrict) (D.1934 + 20) =3D *(int * restrict) (D.1936 + 20); > > =A0*(int * restrict) (D.1934 + 24) =3D *(int * restrict) (D.1936 + 24); > > =A0*(int * restrict) (D.1934 + 28) =3D *(int * restrict) (D.1936 + 28); > > =A0*(int * restrict) (D.1934 + 32) =3D *(int * restrict) (D.1936 + 32); > > =A0*(int * restrict) (D.1934 + 36) =3D *(int * restrict) (D.1936 + 36); > > =A0*(int * restrict) (D.1934 + 40) =3D *(int * restrict) (D.1936 + 40); > > =A0*(int * restrict) (D.1934 + 44) =3D *(int * restrict) (D.1936 + 44); > > =A0*(int * restrict) (D.1934 + 48) =3D *(int * restrict) (D.1936 + 48); > > =A0*(int * restrict) (D.1934 + 52) =3D *(int * restrict) (D.1936 + 52); > > =A0*(int * restrict) (D.1934 + 56) =3D *(int * restrict) (D.1936 + 56); > > =A0*(int * restrict) (D.1934 + 60) =3D *(int * restrict) (D.1936 + 60); > > > > If we agree these tree statements still preserve the=20 > meaning of restrict, > > it should be RTL expansion going wrong. Am I right? >=20 > No, it is TER that removes the temporary that is required to make > restrict work. Try -fno-tree-ter or fixing TER to not TER > to-restrict-pointer conversions. >=20 > Richard. >=20 > > > > - Bingfeng > > > > > >> -----Original Message----- > >> From: Richard Guenther [mailto:richard.guenther@gmail.com] > >> Sent: 03 June 2009 11:54 > >> To: Bingfeng Mei > >> Cc: gcc@gcc.gnu.org > >> Subject: Re: Restrict keyword doesn't work correctly in GCC 4.4 > >> > >> On Wed, Jun 3, 2009 at 12:41 PM, Bingfeng Mei > >> wrote: > >> > Hello, > >> > I noticed that the restrict doesn't work fully on 4.4.0 > >> (used to work on > >> > =A0our port based on 4.3 branch). The problem is that tree > >> optimizer can do a > >> > lot of optimization regarding pointer, e.g., at -O3. The > >> alias set property > >> > is not propagated accordingly. > >> > > >> > Is the following RTL expansion correct? Both read and write > >> address are > >> > converted to a restrict pointer, but the both mem rtx have > >> the same alias set (2). > >> > > >> > ;; *(int * restrict) (D.1768 + 4) =3D *(int * restrict)=20 > (D.1770 + 4); > >> > >> restrict only works if there is a restrict qualified=20 > pointer decl in > >> your source. > >> > >> I will re-implement restrict support completely for 4.5. > >> > >> You can try the attached hack which might help (but also cause > >> weird effects ...). > >> > >> Richard. > >> > >> > (insn 56 55 57 tst.c:7 (set (reg:SI 124) > >> > =A0 =A0 =A0 =A0(mem:SI (plus:SI (reg:SI 103 [ D.1770 ]) > >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(const_int 4 [0x4])) [2 S4 A32])) -1 = (nil)) > >> > > >> > (insn 57 56 0 tst.c:7 (set (mem:SI (plus:SI (reg:SI 104=20 > [ D.1768 ]) > >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(const_int 4 [0x4])) [2 S4 A32]) > >> > =A0 =A0 =A0 =A0(reg:SI 124)) -1 (nil)) > >> > > >> > > >> > The alias set property is copied from tree node: > >> > =A0 >> > =A0 =A0type >> > =A0 =A0 =A0 =A0size > >> > =A0 =A0 =A0 =A0unit size > >> > =A0 =A0 =A0 =A0align 32 symtab 0 alias set 2 canonical type > >> 0xf7f122f4 precision 32 min >> -2147483648> max > >> > =A0 =A0 =A0 =A0pointer_to_this > > >> > > >> > =A0 =A0arg 0 >> > =A0 =A0 =A0 =A0type >> 0xf7f122f4 int> > >> > =A0 =A0 =A0 =A0 =A0 =A0sizes-gimplified public unsigned restrict SI > >> size unit size 0xf7f0f7c4 4> > >> > =A0 =A0 =A0 =A0 =A0 =A0align 32 symtab 0 alias set -1 canonical type= =20 > 0xf7fa6870> > >> > > >> > =A0 =A0 =A0 =A0arg 0 >> 0xf7f12438 long unsigned int> > >> > =A0 =A0 =A0 =A0 =A0 =A0arg 0 > >> > =A0 =A0 =A0 =A0 =A0 =A0arg 1 > >> > =A0 =A0 =A0 =A0 =A0 =A0tst.c:7:5> > >> > =A0 =A0 =A0 =A0tst.c:7:5> > >> > =A0 =A0tst.c:7:5> > >> > > >> > Is the RTL expansion wrong or the orginal tree node is > >> constructed incorrectly? > >> > > >> > Thanks, > >> > Bingfeng Mei > >> > > >> > Broadcom UK > >> > > >> > > >=20 >=20