From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32311 invoked by alias); 5 Jan 2007 01:18:20 -0000 Received: (qmail 32301 invoked by uid 22791); 5 Jan 2007 01:18:19 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 05 Jan 2007 01:18:14 +0000 Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id l051I7ZH019983; Thu, 4 Jan 2007 17:18:07 -0800 Received: from localhost (whippen.corp.google.com [172.18.117.13]) by zps36.corp.google.com with ESMTP id l051I4KD031202; Thu, 4 Jan 2007 17:18:04 -0800 Received: by localhost (Postfix, from userid 24751) id 07DC3276DC0; Thu, 4 Jan 2007 17:18:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17821.42827.894677.761668@whippen.corp.google.com> Date: Fri, 05 Jan 2007 01:18:00 -0000 To: Zdenek Dvorak Cc: Robert Kennedy , Richard Guenther , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fold more aggressively for trip counts In-Reply-To: <20070104225900.GA28248@atrey.karlin.mff.cuni.cz> References: <17821.22245.42440.581996@whippen.corp.google.com> <20070104225900.GA28248@atrey.karlin.mff.cuni.cz> X-Mailer: VM 7.19 under Emacs 21.4.1 Reply-To: Robert Kennedy From: jimbob@google.com (Robert Kennedy) 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-01/txt/msg00310.txt.bz2 > > + TODO: Consider iterating here through copies instead of checking > > + just one level up. */ > implementing the TODO you mention here looks quite dangerous, asking for > serious performance problems. I assume you mean that you are concerned about an increase in compilation time. That's why I said "consider." It would need to be considered, implemented, and tested to make sure it didn't cause trouble. But I would be willing to simply remove that part of the comment if you prefer. > I am not sure making tree_simplify_using_condition > more complex is a good idea -- for what kind of expressions do you > need this change? We discussed this a little bit privately in the past, but I don't think I made clear the connection between that discussion and this change. The situation is that you have a trip-countable loop guarded by an if condition, and after SR/LFTR, the loop termination test is replaced but the guard is not. As a result, slightly more sophistication is needed to compute the trip count for the loop while taking into account the guard. Example: for (i = 0; i < n; i++) body(i * 4); becomes: if (n > 0) { i = 0; do { body(i * 4); i++; } while (i < n); } In that form, the do {} while loop is trip-countable without my change because the (n > 0) guard proves easily that n cannot be negative inside the "then" block. But now with SR/LFTR, the code becomes: if (n > 0) { osrtemp.i = 0; osrtemp.n = n * 4; do { body(osrtemp.i); osrtemp.i += 4; } while (osrtemp.i < osrtemp.n); } If the trip count needs to be computed after such a transformation, my change is needed because now the loop termination test involves variables different from the ones in the guarding "if" condition. > Also, I think you should provide some measurements supporting the > need for this change -- i.e., verify that it does not increase > compile time... What is the accepted way of measuring compile time? Thanks for your comments! -- Robert