From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82356 invoked by alias); 8 Aug 2019 15:55:04 -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 82348 invoked by uid 89); 8 Aug 2019 15:55:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=foldconstc, fold-const.c, UD:fold-const.c, AFAICS 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; Thu, 08 Aug 2019 15:55:03 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 490C8AC1C for ; Thu, 8 Aug 2019 15:55:01 +0000 (UTC) Date: Thu, 08 Aug 2019 16:29:00 -0000 From: Michael Matz To: Martin Liska cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH 5/9] Come up with an abstraction. In-Reply-To: <24e91baf28c01421ba05c877e00c058a2008a5cc.1565105736.git.mliska@suse.cz> Message-ID: References: <24e91baf28c01421ba05c877e00c058a2008a5cc.1565105736.git.mliska@suse.cz> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00565.txt.bz2 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. 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)? 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.