From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64853 invoked by alias); 17 Oct 2015 16:52: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 64842 invoked by uid 89); 17 Oct 2015 16:52:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,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; Sat, 17 Oct 2015 16:52:56 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id D4E2C542C62; Sat, 17 Oct 2015 18:52:52 +0200 (CEST) Date: Sat, 17 Oct 2015 18:57:00 -0000 From: Jan Hubicka To: Richard Biener Cc: Eric Botcazou , gcc-patches@gcc.gnu.org, Jan Hubicka Subject: Re: Add VIEW_CONVERT_EXPR to operand_equal_p Message-ID: <20151017165252.GJ5527@kam.mff.cuni.cz> References: <20151014162944.GE16672@kam.mff.cuni.cz> <3370546.VBkdrdfpOC@polaris> <561AF610-CD06-42B2-838B-5130691978CC@gmail.com> <6178124.DYpozsCQOi@polaris> <6561C1C3-366A-411C-BAEE-65E1C233BA16@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6561C1C3-366A-411C-BAEE-65E1C233BA16@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-10/txt/msg01670.txt.bz2 > >And AFAIK nobody answered the question: what do we gain by making this > >change? > >So far I have only seen breakages, suspicious fixes and code > >duplication... > > Honza wants the structural equality predicate (operand_equal_p) complete (optimistically) for GIMPLE. There are two independent things - operand_equal_p changes and useless_type_conversion changes. operand_equal_p =============== What I want to do is to merge logic of ipa-icf-gimple's func_checker::compare_operand and operand_equal_p so we don't have two incomplette and duplicated ways to say if two gimple operands are equal, but one that does it right. Main problem of func_checker::compare_operand is that it is confused about matching types, producing too many false negatives. Because ipa-icf works as a propagation engine, gving up on one equivalnce leads to a cascaded effect. operand_equal_p does handle types better, but on the other hand it does not handle few trees that we need to match. - CONSTRUCTOR - VIEW_CONVERT_EXPR - OBJ_TYPE_REF The plan is to add these into operand_equal_p and implement interface for valueizing hook that can be used by ipa-icf-gimple to match objects cross function boundary (for example say that two SSA_NAMEs are equal) and drop func_checker::compare_operand usless_type_conversion ====================== I was only tracking one isse I hit: Fortran/C interoperability nees LTO to produce same TYPE_CANONICAl for signed and unsigned version of size_t. Doing so broke useless_type_conversion because it used TYPE_CANONICAL. We discussed the topic on the GNU Cauldron and decided that it is cleaner to drop TYPE_CANONICAL from useless_type_conversion because it does not really belong there. That is only change I plan into the area. The decision to drop comparsion of TYPE_MODE from the aggregate path was decision of the discussion about this particular patch and I do not really insist on it. Having fewer VCE expressions in the code is not a bad thing, but I do not really see it as an important change. I am sorry for the breakage in move expansion that I hoped to not be as important. I am willing to continue fixing the fallout (and be more cureful about it - obviously I originally underestimated the issue). I am also happy with simply adding back the mode checking and drop the changes we did to expr.c so far. Honza