From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65298 invoked by alias); 12 Aug 2019 11:40:59 -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 65290 invoked by uid 89); 12 Aug 2019 11:40:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-lf1-f65.google.com Received: from mail-lf1-f65.google.com (HELO mail-lf1-f65.google.com) (209.85.167.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Aug 2019 11:40:56 +0000 Received: by mail-lf1-f65.google.com with SMTP id b17so73991940lff.7 for ; Mon, 12 Aug 2019 04:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IHoZDFn/JMv0YFJLkZlZOquUa29t7TDINjJTT2cm2ac=; b=u1P1iwHs1HmsNL+3u9BtVTMMLtgP/83mZJR7FbJCGE3I6xA7Cf07Z23eBWehcovemf Q9si9abKdZAZccNBvkm0YjM4ahMYzEsjEtI8xPGisuWacgZvbcMT18/EpG9l4HvgmMrU GoSRhv9c57BkhhWhXwkSGztJbYWYr1tARvQF8kSOMPvu7MyoEUg10UF1uG7yk/Bh8SLy x3LqRhKWGL/qWOf/mcpInJ4dlGErkzAoOKHt+tvdMAFNgZwdCdACzry6j18rFeynzFcg fnlmTC/f6wlxwLL0PVy6z/c2SkqH4iLjGf/JcwzMVEA8ZaHR8dkI+8TzeU2rBetEXCAo bgkQ== MIME-Version: 1.0 References: <24e91baf28c01421ba05c877e00c058a2008a5cc.1565105736.git.mliska@suse.cz> In-Reply-To: From: Richard Biener Date: Mon, 12 Aug 2019 12:27:00 -0000 Message-ID: Subject: Re: [PATCH 5/9] Come up with an abstraction. To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: Michael Matz , GCC Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00733.txt.bz2 On Mon, Aug 12, 2019 at 1:19 PM Martin Li=C5=A1ka 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_che= cker. > > > 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 func= tion > (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. 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. > > >