Re: [RFC] operand_equal_p with valueization

[Jan Hubicka <hubicka at ucw dot cz>]

> On Fri, 22 May 2015, Jan Hubicka wrote:
> 
> > > 
> > > And no, I'm hesitant to change operand_equal_p too much.  It's
> > > very much deep-rooted into GENERIC.
> > 
> > OK, as another option, i can bring relevant logic from operand_equal_p
> > to ipa-icf and separate it into the compare_operand class like I did.
> > Use it in ipa-icf-gimple now and we can slowly turn other uses of
> > operand_equal into the compare_operand users in middle end.
> > 
> > I agree that operand_equal is bit crazy code and it does not handle quite few
> > things we could do at gimple.  I have nothing against going this direction.
> > (after all I do not like touching fold-const much becuase it works on generic,
> > gimple and FE non-generic and it is not well specified what it should do)
> 
> Yes, I've played with the idea of a GIMPLE specific operand_equal_p 
> multiple times but then the changes required to operand_equal_p were
> small all the times.  And having one piece of code that does sth is
> always good ...
> 
> We might turn operand_equal_p to a "worker" (template?) that

Hmm, OK that is precisely what I was shooting for by this patch.  I went by
wrapping it to a class with valueize helper.  It can be template, too, just it
semed that having the single valueize function lets me do everything I need
without actually needing to duplicate the code.

I can get around templatizing it.  Do you have some outline what interface
would seem more fit>

> operand_equal_p and gimple_operand_equal_p can share (with an extra
> flag whether to turn on GIMPLE stuff and/or valueization).  And
> then simply provide explicit instantiations for the original
> operand_equal_p and a new gimple_operand_equal_p.
> 
> Of course we'll only know if we like that when seeing a patch that
> does this ;0)
> 
> Richard.