From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123430 invoked by alias); 14 Aug 2015 18:32:30 -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 123421 invoked by uid 89); 14 Aug 2015 18:32:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 14 Aug 2015 18:32:29 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 521C940C4D; Fri, 14 Aug 2015 18:32:28 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-104.phx2.redhat.com [10.3.113.104]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7EIWRB6030830; Fri, 14 Aug 2015 14:32:28 -0400 Subject: Re: [PATCH GCC]Improve bound information in loop niter analysis To: Richard Biener , Bin Cheng References: <000401d0c918$d7a2e780$86e8b680$@arm.com> Cc: GCC Patches From: Jeff Law Message-ID: <55CE343B.3020209@redhat.com> Date: Fri, 14 Aug 2015 18:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00824.txt.bz2 On 08/14/2015 02:17 AM, Richard Biener wrote: > 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. It's a bit looser than that. Given two user defined types with the same signedness & precision operand_equal_p will consider the types OK. One could argue that it ought to be using the useless type conversion check. jeff