From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29642 invoked by alias); 19 May 2016 11:24:32 -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 29612 invoked by uid 89); 19 May 2016 11:24:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2060 X-HELO: mail-vk0-f66.google.com Received: from mail-vk0-f66.google.com (HELO mail-vk0-f66.google.com) (209.85.213.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 19 May 2016 11:24:18 +0000 Received: by mail-vk0-f66.google.com with SMTP id c189so11299004vkb.3 for ; Thu, 19 May 2016 04:24:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=Ud51Kyys6LEb1wz8dpN/KaKORv3Xe/rrQmlli2fi3h4=; b=asQBTqLrWmq8iC9hJMaR6D5WZVeGD1SFiipWcJTEaY7vXKUQasOZpkItJ3S0QIWAYc Q5lTlNAaEyyQPDbllA+czYaewhUejbPwj5meWotO6rTJ0/fiAKvpnOY7Acz1eLvf7rit PKBuDoZNE1RLsOtlYL7EwgXI/rJumo/zGa+0/+DgpHFIkdjkLEJVXYe2qOamr/JVHplX Da6xPHS0eizKKCExDn+4Ksl9zjmdx76m+tG1SWjKedlId+NLEEfsAOts0+D5e0ptdDQH o9Qn36Ee55zSdni/UdIzGov4ksEERqdg66hFB0Yw7RjTOJOo2Fv+sAEiPFgklrdkKywW ippA== X-Gm-Message-State: AOPr4FWiRGFvU9fgtpSseFFDmILgZSB0vpwnaENxCqj/Uod6wNUEo7lLHMOInLoxHFbBfDeZEbNohjorly2aCQ== MIME-Version: 1.0 X-Received: by 10.159.32.72 with SMTP id 66mr6914009uam.2.1463657056381; Thu, 19 May 2016 04:24:16 -0700 (PDT) Received: by 10.103.44.148 with HTTP; Thu, 19 May 2016 04:24:16 -0700 (PDT) In-Reply-To: <573D941C.4070507@suse.cz> References: <5739D143.1070300@suse.cz> <573D941C.4070507@suse.cz> Date: Thu, 19 May 2016 11:24:00 -0000 Message-ID: Subject: Re: [PATCH 1/3] Encapsulate comp_cost within a class with methods. From: "Bin.Cheng" To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: gcc-patches List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg01476.txt.bz2 On Thu, May 19, 2016 at 11:23 AM, Martin Li=C5=A1ka wrote: > On 05/16/2016 03:55 PM, Martin Li=C5=A1ka wrote: >> On 05/16/2016 12:13 PM, Bin.Cheng wrote: >>> Hi Martin, >>> Could you please rebase this patch and the profiling one against >>> latest trunk? The third patch was applied before these two now. >>> >>> Thanks, >>> bin >> >> Hello. >> >> Sending the rebased version of the patch. >> >> Martin >> > > Hello. > > As I've dramatically changed the 2/3 PATCH, a class encapsulation is not = needed any longer. > Thus, I've reduced this patch just to usage of member function/operators = that are useful > in my eyes. It's up the Bin whether to merge the patch? Yes, I think we want c++-ify such structures. > +comp_cost > +operator- (comp_cost cost1, comp_cost cost2) > +{ > + if (cost1.infinite_cost_p () || cost2.infinite_cost_p ()) > + return comp_cost::get_infinite (); > + > + cost1.cost -=3D cost2.cost; > + cost1.complexity -=3D cost2.complexity; > + > + return cost1; > +} For subtraction, should we expect the second operand as infinite? Maybe add an assertion for it in case anything goes wrong here. > +comp_cost > +comp_cost::get_infinite () > +{ > + return comp_cost (INFTY, INFTY); > +} > + > +comp_cost > +comp_cost::get_no_cost () > +{ > + return comp_cost (); > +} I think we may keep the original global variables for no_cost&infinite_cost, and save these two methods. > > @@ -5982,11 +6083,11 @@ iv_ca_recount_cost (struct ivopts_data *data, str= uct iv_ca *ivs) > { > comp_cost cost =3D ivs->cand_use_cost; > > - cost.cost +=3D ivs->cand_cost; > + cost+=3D ivs->cand_cost; Space. This is pure refactoring, could you please make sure there is no falls out by simply comparing SPEC code generation/disassembly? I am asking since cost computation is sensitive, last time we didn't catch a "*" character typo in dump info improvement patch. Okay with above changes, unless somebody else has comment on the C++ part (which I know very little about). Thanks, bin > > Martin