From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9058 invoked by alias); 26 May 2015 17:36:51 -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 9046 invoked by uid 89); 26 May 2015 17:36:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 26 May 2015 17:36:50 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id B6FB6541031; Tue, 26 May 2015 19:36:46 +0200 (CEST) Date: Tue, 26 May 2015 19:09:00 -0000 From: Jan Hubicka To: Richard Biener Cc: Jan Hubicka , gcc-patches@gcc.gnu.org Subject: Re: [RFC] operand_equal_p with valueization Message-ID: <20150526173646.GE43680@kam.mff.cuni.cz> References: <20150522123600.GE91616@kam.mff.cuni.cz> <20150522135338.GF75713@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-05/txt/msg02365.txt.bz2 > 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.