From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24825 invoked by alias); 16 May 2012 17:15:20 -0000 Received: (qmail 24787 invoked by uid 22791); 16 May 2012 17:15:15 -0000 X-SWARE-Spam-Status: No, hits=-7.3 required=5.0 tests=AWL,BAYES_00,KHOP_PGP_SIGNED,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 May 2012 17:14:55 +0000 Received: from nat-dem.mentorg.com ([195.212.93.2] helo=eu2-mail.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1SUhoL-0000KG-DN from Thomas_Schwinge@mentor.com ; Wed, 16 May 2012 10:14:53 -0700 Received: from feldtkeller.schwinge.homeip.net ([172.30.64.32]) by eu2-mail.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 May 2012 19:14:51 +0200 From: Thomas Schwinge To: Jakub Jelinek Cc: Richard Guenther , Bernd Schmidt , Richard Earnshaw , Joey Ye , "dj\@redhat.com" , GCC Patches , "Mitchell\, Mark" Subject: Re: Continue strict-volatile-bitfields fixes In-Reply-To: <874nrqaz8s.fsf@schwinge.name> References: <4F428565.1050508@arm.com> <4F42881B.80800@codesourcery.com> <4F436677.9090203@arm.com> <87obqpnj9i.fsf@schwinge.name> <4F8EE84C.20501@arm.com> <4F8EE8E0.6020907@codesourcery.com> <871unjobrq.fsf@schwinge.name> <878vhkqcep.fsf@schwinge.name> <87ipglkcou.fsf@schwinge.name> <20120427082906.GD16117@tyan-ft48-01.lab.bos.redhat.com> <874nrqaz8s.fsf@schwinge.name> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Wed, 16 May 2012 17:15:00 -0000 Message-ID: <87sjf0qc8q.fsf@schwinge.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-05/txt/msg01156.txt.bz2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 2527 Hi! Ping. On Wed, 09 May 2012 10:01:55 +0800, I wrote: > On Fri, 27 Apr 2012 10:29:06 +0200, Jakub Jelinek wrot= e: > > On Fri, Apr 27, 2012 at 12:42:41PM +0800, Thomas Schwinge wrote: > > > > > GET_MODE_BITSIZE (lmode)=C2=AB (8 bits). =C2=A0(With the current = sources, lmode is > > > > > VOIDmode.) > > > > > > > > > > Is emmitting =C2=BBBIT_FIELD_REF <*common, 32, 0> & 255=C2=AB wro= ng in this case, > > > > > or should a later optimization pass be able to figure out that > > > > > =C2=BBBIT_FIELD_REF <*common, 32, 0> & 255=C2=AB is in fact the s= ame as > > > > > common->code, and then be able to conflate these? =C2=A0Any sugge= stions > > > > > where/how to tackle this? > > > >=20 > > > > The BIT_FIELD_REF is somewhat of a red-herring. It is created by f= old-const.c > > > > in optimize_bit_field_compare, code that I think should be removed = completely. > > > > Or it needs to be made aware of strict-volatile bitfield and C++ me= mory model > > > > details. > >=20 > > I'd actually very much prefer the latter, just disable > > optimize_bit_field_compare for strict-volatile bitfield mode and when > > avoiding load data races in C++ memory model (that isn't going to be > > default, right?). This optimization is useful, and it is solely about > > loads, so even C++ memory model usually shouldn't care. >=20 > I can't comment on the C++ memory model bits, but I have now tested the > following patch (fixes the issue for SH, no regressions for ARM, x86): >=20 > gcc/ > * fold-const.c (optimize_bit_field_compare): Abort early in the strict > volatile bitfields case. >=20 > Index: fold-const.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- fold-const.c (revision 186856) > +++ fold-const.c (working copy) > @@ -3342,6 +3342,11 @@ optimize_bit_field_compare (location_t loc, enum t > tree mask; > tree offset; >=20=20 > + /* In the strict volatile bitfields case, doing code changes here may = prevent > + other optimizations, in particular in a SLOW_BYTE_ACCESS setting. = */ > + if (flag_strict_volatile_bitfields > 0) > + return 0; > + > /* Get all the information about the extractions being done. If the b= it size > if the same as the size of the underlying object, we aren't doing an > extraction at all and so can do nothing. We also don't want to Gr=C3=BC=C3=9Fe, Thomas --=-=-= Content-Type: application/pgp-signature Content-length: 489 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJPs+CGAAoJENuKOtuXzphJ/twIALa395PPt5NRAVjvLgohUgVw iBaAdbXU8aoDcQqv8WWkqF1EME1Cz0RDIl9G0jH/PEaQPOOgAfcQspk2VOxHeLAe 0OKAc53tpRCMavmbAi6jS5iC3tgAq/TvzcNhbIO2Q12uDJulh0Pp7cTT81/MSKHQ eWz0k0Eaxgo4HFTP6LqklQ6mhOjBOkWMiduj9cA1e/OX8i9Hj9bDJUVkyh88qBkv kAfxZpw13JsznyPtOUUmWJjes7qhyLzaspohldmcwdpvSqYR4n6eNKmbv3XZH2FC WxRScun7/FsP/Jpi8XNe3mczdeU502VMflRJ/1EkUDtHCIATReeksGyMmccLXZg= =LLrz -----END PGP SIGNATURE----- --=-=-=--