From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1174 invoked by alias); 9 Nov 2011 08:48:56 -0000 Received: (qmail 1166 invoked by uid 22791); 9 Nov 2011 08:48:55 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-yx0-f175.google.com (HELO mail-yx0-f175.google.com) (209.85.213.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Nov 2011 08:48:41 +0000 Received: by yenm3 with SMTP id m3so492800yen.20 for ; Wed, 09 Nov 2011 00:48:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.74.37 with SMTP id q5mr288940obv.32.1320828520709; Wed, 09 Nov 2011 00:48:40 -0800 (PST) Received: by 10.182.17.232 with HTTP; Wed, 9 Nov 2011 00:48:40 -0800 (PST) In-Reply-To: <4EB9846E.9040802@redhat.com> References: <20111107212547.GO27375@tyan-ft48-01.lab.bos.redhat.com> <4EB9846E.9040802@redhat.com> Date: Wed, 09 Nov 2011 09:42:00 -0000 Message-ID: Subject: Re: [PATCH] Improve VEC_BASE From: Richard Guenther To: Jeff Law Cc: Jakub Jelinek , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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: 2011-11/txt/msg01292.txt.bz2 On Tue, Nov 8, 2011 at 8:35 PM, Jeff Law wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/07/11 15:53, Richard Guenther wrote: >> On Mon, Nov 7, 2011 at 10:25 PM, Jakub Jelinek >> wrote: >>> Hi! >>> >>> This patch attempts to optimize VEC_BASE if we know that offsetof >>> of base is 0 (unless the compiler is doing something strange, it >>> is true). It doesn't have a clear code size effect, some .text >>> sections grew, supposedly because of more inlining, some .text >>> sections shrunk. >>> >>> Bootstrapped/regtested on x86_64-linux and i686-linux. >> >> I wonder why the compiler doesn't optimize this ... certainly it >> looks backward to, in >> >> : if (c_2(D) !=3D 0B) goto ; else goto ; >> >> : D.2948_3 =3D &c_2(D)->fld; goto ; >> >> : D.2948_4 =3D 0B; >> >> : # D.2948_1 =3D PHI return D.2948_1; >> >> see that D.2948_4 is equal to D.2948_3 for c_2 =3D=3D 0, so I'm not >> sure which pass would be able to detect this (but the optimziation >> opportunity would be on the PHI node, so maybe it should be done in >> phiopt). > Right, I see that now. > > But D2948_3 doesn't flow through block #4, thus we can't use its value > for the PHI arg associated with the edge 4->5. =A0So even with the > equivalency =A0I think to optimize this we'd have to detect the > construct as a whole and collapse it into &c_2->fld. > > Presumably that's what your patch in a later message does. Yes. It collapses it into c_2. As pointer type differences are no longer important in the GIMPLE IL we can represent &c_2->fld simply as c_2 and thus with copy propagation we'd present phiopt with something it already handles. Unfortunately rewriting all &c_2->fld style expressions simply as c_2 plays foul with _FORTIFY_SOURCE and object size computation (where it makes a difference which field at offset zero you access ...). So instead of canonicalizing address computations using ADDR_EXPR to POINTER_PLUS_EXPR in general for 4.7 the only thing we can do is special case the above case in phiopt (which is probably worthwhile - that pattern ought to be quite common). Richard. > jeff > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJOuYRuAAoJEBRtltQi2kC7E2YH/1ayeLWX3GoOnq5u+JxpyWkx > Fh/Dnar+Ad2jJJMrbx7vUUhAH54OEUDTWKYMQOn8ThUTnMmQtgb4uNqdyO78RfyM > BIVzzpTjD3Ud1+xxlzg8YCjvBw/NekRp9l4HiZpwwRIfTQRpKhWZ+oWe3bBgs+4B > LCVQWA9I5cGBhv09u7OOsYhicuAUa1Tj/XNF4NWE1GVsjilj+ESvZUj5Zd7dvxft > QzGh0fNn+RB9LVu6kktvU5CCX/sVBjVDnTaOP14zYGAEMFrWYjanE0n9+b6cVf9W > degmRowfMzOLvphsWEPFVZCTJPuDfkLlc5k6X3MkgpEFwQu6uo2S/k8vd98PAr8=3D > =3Dvcgh > -----END PGP SIGNATURE----- >