This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 5/9] Come up with an abstraction.
On 8/8/19 5:55 PM, Michael Matz wrote:
> On Mon, 10 Jun 2019, Martin Liska wrote:
>> 2019-07-24 Martin Liska <email@example.com>
>> * 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?
> 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.