From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11348 invoked by alias); 11 Apr 2012 09:25:33 -0000 Received: (qmail 11328 invoked by uid 22791); 11 Apr 2012 09:25:31 -0000 X-SWARE-Spam-Status: No, hits=-4.7 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 X-Spam-Check-By: sourceware.org Received: from mail-gx0-f175.google.com (HELO mail-gx0-f175.google.com) (209.85.161.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 Apr 2012 09:25:12 +0000 Received: by ggcy3 with SMTP id y3so343148ggc.20 for ; Wed, 11 Apr 2012 02:25:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.175.232 with SMTP id z68mr9796836yhl.95.1334136311650; Wed, 11 Apr 2012 02:25:11 -0700 (PDT) Received: by 10.147.153.12 with HTTP; Wed, 11 Apr 2012 02:25:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Apr 2012 09:25:00 -0000 Message-ID: Subject: Re: Missed optimization in PRE? From: "Bin.Cheng" To: Richard Guenther 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/msg00399.txt.bz2 On Wed, Apr 11, 2012 at 5:09 PM, Richard Guenther wrote: > On Wed, Apr 11, 2012 at 10:05 AM, Bin.Cheng wrote: >> On Wed, Apr 11, 2012 at 11:28 AM, Bin.Cheng wrot= e: >> >> 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) { int i; for (i =3D 0; i < N/2; ++i) { int d0 =3D d[2*i], e0 =3D e[2*i]; int d1 =3D d[2*i+1], e1 =3D e[2*i+1]; k[2*i] =3D a[2*i] >=3D b[2*i] ? d0 : e0; k[2*i+1] =3D a[2*i+1] >=3D b[2*i+1] ? d1 : e1; } } The load "d[2*i+1]" is never out-of-bound, right? > >> 2, Should I check this before sinking load from memory? If yes, then why= 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 the= y may > not trap if they were originally not executed. > > So this is a pass ordering issue - sinking and if-conversion have differe= nt > conflicting goals. =A0Btw, you also make RTL if-conversion harder. =A0I s= uppose 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 preserv= ed > (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 n= ot sure whether this is still wanted in GCC. Thanks. --=20 Best Regards.