From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11322 invoked by alias); 17 Apr 2019 07:10:12 -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 11314 invoked by uid 89); 17 Apr 2019 07:10:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.1 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= 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 ESMTP; Wed, 17 Apr 2019 07:10:10 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3B6943091761; Wed, 17 Apr 2019 07:10:09 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.40.205.45]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D1CE8608C6; Wed, 17 Apr 2019 07:10:07 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id x3H7A2lR004805; Wed, 17 Apr 2019 09:10:03 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x3H7A1ll004804; Wed, 17 Apr 2019 09:10:01 +0200 Date: Wed, 17 Apr 2019 07:19:00 -0000 From: Jakub Jelinek To: "bin.cheng" Cc: GCC Patches Subject: Re: [PATCH PR90078]Capping comp_cost computation in ivopts Message-ID: <20190417071001.GR21066@tucnak> Reply-To: Jakub Jelinek References: <7cb22a67-89e5-45d3-aef4-398311416140.bin.cheng@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7cb22a67-89e5-45d3-aef4-398311416140.bin.cheng@linux.alibaba.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00676.txt.bz2 On Wed, Apr 17, 2019 at 02:13:12PM +0800, bin.cheng wrote: > Hi, > As discussed in PR90078, this patch checks possible infinite_cost overflow in ivopts. > Also as discussed, overflow happens mostly because of cost scaling wrto bb_freq/loop_freq. > For the moment, we only implement capping in comp_cost operators, while in next > stage1, we may instead implement capping in get_scaled_computation_cost_at with > more supporting benchmark data. > > BTW, I think switching costs around comparison between infinite_cost is unnecessary > since there will be no overflow in integer after capping with infinite_cost. > > Bootstrap and test on x86_64, is it OK? > > Thanks, > bin > > 2019-04-17 Bin Cheng > > PR tree-optimization/92078 > * tree-ssa-loop-ivopts.c (comp_cost::operator +,-,+=,-+,/=,*=): Add > checks for infinite_cost overflow. > > 2018-04-17 Bin Cheng > > PR tree-optimization/92078 > * gcc/testsuite/g++.dg/tree-ssa/pr90078.C: New test. --- a/gcc/tree-ssa-loop-ivopts.c +++ b/gcc/tree-ssa-loop-ivopts.c @@ -243,6 +243,9 @@ operator+ (comp_cost cost1, comp_cost cost2) if (cost1.infinite_cost_p () || cost2.infinite_cost_p ()) return infinite_cost; + if (cost1.cost + cost2.cost >= infinite_cost.cost) + return infinite_cost; As #define INFTY 10000000 what is the reason to keep the previous condition as well? I mean, if cost1.cost == INFTY or cost2.cost == INFTY, cost1.cost + cost2.cost >= INFTY too. Unless costs can go negative. @@ -256,6 +259,8 @@ operator- (comp_cost cost1, comp_cost cost2) return infinite_cost; gcc_assert (!cost2.infinite_cost_p ()); + if (cost1.cost - cost2.cost >= infinite_cost.cost) + return infinite_cost; Unless costs can be negative, when you first bail out for cost1.cost == INFTY, then cost1.cost - cost2.cost won't be INFTY (but could get negative). So shouldn't there be a guard against that instead? Or, if costs can be negative, shouldn't there be also guards that it doesn't grow too negative (say smaller than -INFTY)? Jakub