From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23539 invoked by alias); 12 Oct 2007 21:08:42 -0000 Received: (qmail 23530 invoked by uid 22791); 12 Oct 2007 21:08:42 -0000 X-Spam-Check-By: sourceware.org Received: from rv-out-0910.google.com (HELO rv-out-0910.google.com) (209.85.198.189) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 Oct 2007 21:08:40 +0000 Received: by rv-out-0910.google.com with SMTP id f5so806788rvb for ; Fri, 12 Oct 2007 14:08:38 -0700 (PDT) Received: by 10.141.145.11 with SMTP id x11mr1766890rvn.1192223318094; Fri, 12 Oct 2007 14:08:38 -0700 (PDT) Received: by 10.140.194.11 with HTTP; Fri, 12 Oct 2007 14:08:38 -0700 (PDT) Message-ID: Date: Fri, 12 Oct 2007 21:08:00 -0000 From: "Sebastian Pop" To: "Zdenek Dvorak" Subject: Re: Preliminary patch for PR23820 and PR24309 Cc: "GCC Patches" In-Reply-To: <20071012011640.GA16964@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071012011640.GA16964@kam.mff.cuni.cz> 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: 2007-10/txt/msg00776.txt.bz2 On 10/11/07, Zdenek Dvorak wrote: > > cfg cleanup does that in gcc. > That's not helping removing these BBs as they are just before a BB with more than one entry, so they are considered as loop latch BBs. I'm still thinking about how to adapt the analyzer to not reject ltrans-3.c and not to fail on the two PRs, but the pattern in these three cases is exactly the same, I cannot distinguish in between: all the statements outside the innermost loop are just either conditions, or the update of the main induction variable. I would like to have a more strict definition of perfectly nested loops, by forbidding more than a COND_EXPR in the body of the outer loops: i.e. the only COND_EXPR of the outer loop should be the exit condition. But this is too strict for the case in ltrans-3.c. Do we have an option to XFAIL ltrans-3.c? And of course, file an optimization PR for the following problem: The code for ltrans-3.c is double u[1782225]; int foo(int N, int *res) { unsigned int i, j; double sum = 0; for (i = 0; i < N; i++) { for (j = 0; j < N; j++) { sum = sum + u[i + 1335 * j]; } } *res = sum + N; } we check that N != 0 before entering the first loop, and also inside this loop, we check for the exact same expression N != 0 before entering the innermost loop. N not being modified in between these two checks, the second cond_expr is redundant. VRP or a constant propagator could be adapted to optimize this kind of double checking. Sebastian