From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27196 invoked by alias); 30 Mar 2011 12:22:44 -0000 Received: (qmail 27186 invoked by uid 22791); 30 Mar 2011 12:22:42 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,TW_FC X-Spam-Check-By: sourceware.org Received: from mail-gw0-f47.google.com (HELO mail-gw0-f47.google.com) (74.125.83.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 30 Mar 2011 12:22:38 +0000 Received: by gwb11 with SMTP id 11so630281gwb.20 for ; Wed, 30 Mar 2011 05:22:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.63.3 with SMTP id q3mr1374693ybk.443.1301487757330; Wed, 30 Mar 2011 05:22:37 -0700 (PDT) Received: by 10.150.92.11 with HTTP; Wed, 30 Mar 2011 05:22:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Mar 2011 12:41:00 -0000 Message-ID: Subject: Re: [RFC][patch] If-conversion of COMPONENT_REFs From: Ira Rosen To: Richard Guenther Cc: gcc-patches@gcc.gnu.org, Patch Tracking Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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-03/txt/msg02062.txt.bz2 On 30 March 2011 12:59, Richard Guenther wrote: > On Wed, Mar 30, 2011 at 11:13 AM, Ira Rosen wrote: >> Hi, >> >> With this patch a data-ref is marked as unconditionally read or >> written also if its adjacent field is read or written unconditionally >> in the loop. >> My concern is that this is not safe enough, even though the fields >> have to be non-pointers and non-aggregates, and this optimization is >> applied only with -ftree-loop-if-convert-stores flag. >> >> Bootstrapped on powerpc64-suse-linux and tested on x86_64-suse-linux. >> >> OK for trunk? > > The restrictions do not make too much sense to me. =A0For the C++ > memory model we can't do speculative stores at all, but for the > rest I'd say just checking if the data-refs access the same object > is enough, thus, instead of same_data_refs (a, b) simply check > operand_equal_p (DR_BASE_ADDRESS (a), DR_BASE_ADDRESS (b), 0) > or operand_equal_p (get_base_address (DR_REF (a)), get_base_address > (DR_REF (b)), 0), whatever makes more sense (I always confuse what > the contents of the various DR fields are). But what about int a[10], b[100], c[100]; for (i =3D 0; i < 100; i++) { if (i < 10) t =3D a[i]; else t =3D b[i]; c[i] =3D t + a[1]; } We can't transform this to int a[10], b[100], c[100]; for (i =3D 0; i < 100; i++) { t1 =3D a[i]; t2 =3D b[i]; t =3D (i < 10) ? t1 : t2; c[i] =3D t + a[1]; } since we create accesses to a[10:100], right? Thanks, Ira > > Thanks, > Richard. > >> Thanks, >> Ira >> >> >> ChangeLog: >> >> =A0 =A0 =A0 =A0 * tree-if-conv.c (memrefs_read_or_written_unconditionall= y): Return true >> =A0 =A0 =A0 =A0 if an adjacent field of the data-ref is accessed uncondi= tionally. >> >> testsuite/ChangeLog: >> >> =A0 =A0 =A0 =A0 * gcc.dg/vect/if-cvt-stores-vect-ifcvt-18.c: New test. >> =A0 =A0 =A0 =A0 * gcc.dg/vect/vect.exp: Run if-cvt-stores-vect* tests wi= th >> =A0 =A0 =A0 =A0 -ftree-loop-if-convert-stores. >> >