From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107716 invoked by alias); 14 Aug 2015 08:17:04 -0000 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 Received: (qmail 107707 invoked by uid 89); 14 Aug 2015 08:17:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ig0-f173.google.com Received: from mail-ig0-f173.google.com (HELO mail-ig0-f173.google.com) (209.85.213.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 14 Aug 2015 08:17:02 +0000 Received: by igxp17 with SMTP id p17so7424863igx.1 for ; Fri, 14 Aug 2015 01:17:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.176.138 with SMTP id ci10mr1612598igc.32.1439540220256; Fri, 14 Aug 2015 01:17:00 -0700 (PDT) Received: by 10.107.32.140 with HTTP; Fri, 14 Aug 2015 01:17:00 -0700 (PDT) In-Reply-To: <000401d0c918$d7a2e780$86e8b680$@arm.com> References: <000401d0c918$d7a2e780$86e8b680$@arm.com> Date: Fri, 14 Aug 2015 08:28:00 -0000 Message-ID: Subject: Re: [PATCH GCC]Improve bound information in loop niter analysis From: Richard Biener To: Bin Cheng Cc: GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00761.txt.bz2 On Tue, Jul 28, 2015 at 11:36 AM, Bin Cheng wrote: > Hi, > Loop niter computes inaccurate bound information for different loops. This > patch is to improve it by using loop initial condition in > determine_value_range. Generally, loop niter is computed by subtracting > start var from end var in loop exit condition. Moreover, loop bound is > computed using value range information of both start and end variables. > Basic idea of this patch is to check if loop initial condition implies more > range information for both start/end variables. If yes, we refine range > information and use that to compute loop bound. > With this improvement, more accurate loop bound information is computed for > test cases added by this patch. + c0 = fold_convert (type, c0); + c1 = fold_convert (type, c1); + + if (operand_equal_p (var, c0, 0)) I believe if c0 is not already of type type operand-equal_p will never succeed. (side-note: we should get rid of the GMP use, that's expensive and now we have wide-int available which should do the trick as well) + /* Case of comparing with the bounds of the type. */ + if (TYPE_MIN_VALUE (type) + && operand_equal_p (c1, TYPE_MIN_VALUE (type), 0)) + cmp = GT_EXPR; + if (TYPE_MAX_VALUE (type) + && operand_equal_p (c1, TYPE_MAX_VALUE (type), 0)) + cmp = LT_EXPR; don't use TYPE_MIN/MAX_VALUE. Instead use the types precision and all wide_int operations (see match.pd wi::max_value use). + else if (!operand_equal_p (var, varc0, 0)) + goto end_2; ick - goto. We need sth like a auto_mpz class with a destructor. struct auto_mpz { auto_mpz () { mpz_init (m_val); } ~auto_mpz () { mpz_clear (m_val); } mpz& operator() { return m_val; } mpz m_val; }; > Is it OK? I see the code follows existing practice in niter analysis even though my overall plan was to transition its copying of value-range related optimizations to use VRP infrastructure. I'm still ok with improving the existing code on the basis that I won't get to that for GCC 6. So - ok with the TYPE_MIN/MAX_VALUE change suggested above. Refactoring with auto_mpz welcome. Thanks, RIchard. > Thanks, > bin > > 2015-07-28 Bin Cheng > > * tree-ssa-loop-niter.c (refine_value_range_using_guard): New. > (determine_value_range): Call refine_value_range_using_guard for > each loop initial condition to improve value range. > > gcc/testsuite/ChangeLog > 2015-07-28 Bin Cheng > > * gcc.dg/tree-ssa/loop-bound-1.c: New test. > * gcc.dg/tree-ssa/loop-bound-3.c: New test. > * gcc.dg/tree-ssa/loop-bound-5.c: New test.