From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26319 invoked by alias); 18 Oct 2015 16:06: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 26273 invoked by uid 89); 18 Oct 2015 16:06: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; Sun, 18 Oct 2015 16:06:56 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 151065452CA; Sun, 18 Oct 2015 18:06:51 +0200 (CEST) Date: Sun, 18 Oct 2015 16:37:00 -0000 From: Jan Hubicka To: Eric Botcazou Cc: gcc-patches@gcc.gnu.org, Jan Hubicka , Richard Biener Subject: Re: Add VIEW_CONVERT_EXPR to operand_equal_p Message-ID: <20151018160651.GA63497@kam.mff.cuni.cz> References: <20151014162944.GE16672@kam.mff.cuni.cz> <6561C1C3-366A-411C-BAEE-65E1C233BA16@gmail.com> <20151017165252.GJ5527@kam.mff.cuni.cz> <1833908.my5suBVC6X@polaris> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1833908.my5suBVC6X@polaris> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-10/txt/msg01684.txt.bz2 Hello, > > 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. > > OK, thanks for the explanation. > > > 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. > > I agree on the fewer VCE expressions goal (and I have an upcoming gigi change > to that effect) but some of them are essentially mandated by the RTL level > and, since GENERIC & GIMPLE are ultimately lowered to RTL, they need to take > that into account IMO. So, if the mode change is not really necessary for the > rest of the work, I'd restore the mode check (and this only affects Ada in > practice since apparently only the Ada compiler fiddles with the type mode). Why is Ada fliddling with the modes? Is it only for packed structures? I was wondering how to produce VCE convesions of aggregates with C frontend at all (that is getting them synthetized by the middle-end) to get non-ada testcases. Storing through union is never folded to one and I don't see any other obvious way of getting them. Perhaps it may be possible to get them via inliner on incompatible parameter and LTO, but that seems to be the only case I can think of right now. I am testing the change to compare modes and revert the two expr.c changes. Lets see what is Richard's opinion. The whole concept of modes on aggregate types is bit funny post-tree-ssa days when we do SRA. I suppose they may be tied to calling conventions, but should no longer be needed for code quality? Honza > > -- > Eric Botcazou