From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-307207-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 14087 invoked by alias); 7 Nov 2011 22:53:35 -0000
Received: (qmail 14076 invoked by uid 22791); 7 Nov 2011 22:53:34 -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-vw0-f47.google.com (HELO mail-vw0-f47.google.com) (209.85.212.47)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Nov 2011 22:53:21 +0000
Received: by vwe42 with SMTP id 42so4792053vwe.20        for <gcc-patches@gcc.gnu.org>; Mon, 07 Nov 2011 14:53:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.74.37 with SMTP id q5mr7564636obv.32.1320706400472; Mon, 07 Nov 2011 14:53:20 -0800 (PST)
Received: by 10.182.17.232 with HTTP; Mon, 7 Nov 2011 14:53:20 -0800 (PST)
In-Reply-To: <20111107212547.GO27375@tyan-ft48-01.lab.bos.redhat.com>
References: <20111107212547.GO27375@tyan-ft48-01.lab.bos.redhat.com>
Date: Mon, 07 Nov 2011 23:25:00 -0000
Message-ID: <CAFiYyc3N90CWZsQre972gzZg0b_nvsKXgkr4=J_fSvNystj4mA@mail.gmail.com>
Subject: Re: [PATCH] Improve VEC_BASE
From: Richard Guenther <richard.guenther@gmail.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Jeff Law <law@redhat.com>, 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: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2011-11/txt/msg01097.txt.bz2

On Mon, Nov 7, 2011 at 10:25 PM, Jakub Jelinek <jakub@redhat.com> 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

<bb 2>:
  if (c_2(D) !=3D 0B)
    goto <bb 3>;
  else
    goto <bb 4>;

<bb 3>:
  D.2948_3 =3D &c_2(D)->fld;
  goto <bb 5>;

<bb 4>:
  D.2948_4 =3D 0B;

<bb 5>:
  # D.2948_1 =3D PHI <D.2948_3(3), 0B(4)>
  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).

Would you open a bugreport for this please?

Ok.
Thanks,
Richard.

> 2011-11-07 =A0Jakub Jelinek =A0<jakub@redhat.com>
>
> =A0 =A0 =A0 =A0* vec.h (VEC_BASE): If base is at offset 0 in the structur=
e,
> =A0 =A0 =A0 =A0use &(P)->base even if P is NULL.
>
> --- gcc/vec.h.jj =A0 =A0 =A0 =A02011-09-08 11:21:10.000000000 +0200
> +++ gcc/vec.h =A0 2011-11-07 18:45:33.000000000 +0100
> @@ -549,7 +549,12 @@ typedef struct VEC(T,A) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0\
> =A0} VEC(T,A)
>
> =A0/* Convert to base type. =A0*/
> +#if GCC_VERSION >=3D 4000
> +#define VEC_BASE(P) \
> + =A0((offsetof (__typeof (*P), base) =3D=3D 0 || (P)) ? &(P)->base : 0)
> +#else
> =A0#define VEC_BASE(P) =A0((P) ? &(P)->base : 0)
> +#endif
>
> =A0/* Vector of integer-like object. =A0*/
> =A0#define DEF_VEC_I(T) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
>
> =A0 =A0 =A0 =A0Jakub
>