From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88183 invoked by alias); 12 Aug 2019 11:49:15 -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 88131 invoked by uid 89); 12 Aug 2019 11:49:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Aug 2019 11:49:12 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 581A9B090; Mon, 12 Aug 2019 11:49:10 +0000 (UTC) Subject: Re: [PATCH 5/9] Come up with an abstraction. To: Richard Biener Cc: Michael Matz , GCC Patches References: <24e91baf28c01421ba05c877e00c058a2008a5cc.1565105736.git.mliska@suse.cz> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: <430c1435-a4c9-2960-5542-b95a8c346744@suse.cz> Date: Mon, 12 Aug 2019 12:43:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00734.txt.bz2 On 8/12/19 1:40 PM, Richard Biener wrote: > On Mon, Aug 12, 2019 at 1:19 PM Martin Liška wrote: >> >> On 8/8/19 5:55 PM, Michael Matz wrote: >>> Hi, >>> >>> On Mon, 10 Jun 2019, Martin Liska wrote: >>> >>>> 2019-07-24 Martin Liska >>>> >>>> * fold-const.c (operand_equal_p): Rename to ... >>>> (operand_compare::operand_equal_p): ... this. >>>> (add_expr): Rename to ... >>>> (operand_compare::hash_operand): ... this. >>>> (operand_compare::operand_equal_valueize): Likewise. >>>> (operand_compare::hash_operand_valueize): Likewise. >>>> * fold-const.h (operand_equal_p): Set default >>>> value for last argument. >>>> (class operand_compare): New. >>> >>> Hmpf. A class without any data? That doesn't sound like a good design. >> >> Yes, the base class (current operand_equal_p) does not have a data. >> But the ICF derive class has a data and e.g. func_checker::operand_equal_valueize >> will use m_label_bb_map.get (t1). Which are member data of class func_checker. >> >>> You seem to need it only to have the possibility of virtual functions, >>> i.e. fancy callbacks. AFAICS you only have one derived class, i.e. a >>> simple distinction of two cases. What do you think about encoding the >>> additional new (ICF) case in the (existing) 'flags' argument to >>> operand_equal_p (and in case the ICF flag is set simply call the >>> "callback" directly)? >> >> That's possible. I can add two more callbacks to the operand_equal_p function >> (hash_operand_valueize and operand_equal_valueize). >> >> Is Richi also supporting this approach? > > I still see no value in the abstraction since you invoke none of the > (virtual) methods from the base class operand_equal_p. I call operand_equal_valueize (and hash_operand) from operand_equal_p. These are then used in IPA ICF (patch 6/9). Martin > > Richard. > >> Thanks, >> Martin >> >>> IMHO that would also make the logic within >>> operand_equal_p clearer, because you don't have to think about all the >>> potential callback functions that might be called. >>> >>> >>> Ciao, >>> Michael. >>> >>