From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24518 invoked by alias); 11 Apr 2012 10:02:28 -0000 Received: (qmail 24506 invoked by uid 22791); 11 Apr 2012 10:02:27 -0000 X-SWARE-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_TM X-Spam-Check-By: sourceware.org Received: from mail-iy0-f175.google.com (HELO mail-iy0-f175.google.com) (209.85.210.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 Apr 2012 10:02:14 +0000 Received: by iaag37 with SMTP id g37so1117323iaa.20 for ; Wed, 11 Apr 2012 03:02:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.188.134 with SMTP id ga6mr1420873igc.20.1334138534169; Wed, 11 Apr 2012 03:02:14 -0700 (PDT) Received: by 10.42.228.200 with HTTP; Wed, 11 Apr 2012 03:02:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Apr 2012 10:02:00 -0000 Message-ID: Subject: Re: Missed optimization in PRE? From: Richard Guenther To: "Bin.Cheng" Cc: gcc@gcc.gnu.org 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: 2012-04/txt/msg00404.txt.bz2 On Wed, Apr 11, 2012 at 11:25 AM, Bin.Cheng wrote: > On Wed, Apr 11, 2012 at 5:09 PM, Richard Guenther > wrote: >> On Wed, Apr 11, 2012 at 10:05 AM, Bin.Cheng wrot= e: >>> On Wed, Apr 11, 2012 at 11:28 AM, Bin.Cheng wro= te: > >>> >>> Turns out if-conversion checks whether gimple statement traps or not. >>> For the statement "d0_6 =3D d[D.5150_5];", it assumes rhs might trap, >>> because it sees the index not INTEGER_CST. >> >> Yes. =A0After sinking the load is no longer executed unconditionally but >> if-conversion would make it so. =A0This is information loss caused by >> sinking. >> >>> Two questions: >>> 1, The check can be enhanced in gimple_could_trap_p_1 for ARRAY_REF. >> >> No, the index may be out-of-bounds. > > Apart from this topic. Actually I mean we can do more bound check > rather than assume > out-of-bounds if the index is not CST. > For this example, the source code is like: > > #define N 32 > int a[N], b[N]; > int d[N], e[N]; > int k[N]; > > __attribute__((noinline, noclone)) void > f4 (void) > { > =A0int i; > =A0for (i =3D 0; i < N/2; ++i) > =A0 =A0{ > =A0 =A0 =A0int d0 =3D d[2*i], e0 =3D e[2*i]; > =A0 =A0 =A0int d1 =3D d[2*i+1], e1 =3D e[2*i+1]; > =A0 =A0 =A0k[2*i] =3D a[2*i] >=3D b[2*i] ? d0 : e0; > =A0 =A0 =A0k[2*i+1] =3D a[2*i+1] >=3D b[2*i+1] ? d1 : e1; > =A0 =A0} > } > > The load "d[2*i+1]" is never out-of-bound, right? Right. value-range analysis could set TREE_NO_TRAP on the memory reference. >> >>> 2, Should I check this before sinking load from memory? If yes, then wh= y sink of >>> store does not do such check? >> >> Sinking is never a problem - the code will only be executed less times. = =A0The >> issue with if-conversion is that it speculates the loads / stores, so th= ey may >> not trap if they were originally not executed. >> >> So this is a pass ordering issue - sinking and if-conversion have differ= ent >> conflicting goals. =A0Btw, you also make RTL if-conversion harder. =A0I = suppose > Yes, I have already found a case resulting in bad basic block ordering > at RTL level, > though not sure it RTL if-conversion related. > >> you should try to avoid messing up if-conversion possibilities so early, >> thus, not sink in these cases. =A0The same issue is present >> for non-loads that are possibly trapping. =A0So I'm not even sure we can= easily >> detect these cases - apart from never sinking possibly trapping stmts. >> >> At least you could say that the side-effect of trapping has to be preser= ved >> (note that we do not generally do that, which you might consider a bug). > > Understood. I have already tested to not sink possibly trapping stmt, but= not > sure whether this is still wanted in GCC. In general the sinking is wanted. For non-trapping stmts it would be obvious I think. Richard. > Thanks. > > > -- > Best Regards.