From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124267 invoked by alias); 18 Oct 2015 16:37:18 -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 124253 invoked by uid 89); 18 Oct 2015 16:37:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_20,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f175.google.com Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com) (209.85.212.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sun, 18 Oct 2015 16:37:16 +0000 Received: by wicll6 with SMTP id ll6so66326975wic.0 for ; Sun, 18 Oct 2015 09:37:13 -0700 (PDT) X-Received: by 10.180.35.199 with SMTP id k7mr16875404wij.13.1445186233309; Sun, 18 Oct 2015 09:37:13 -0700 (PDT) Received: from android-4c5a376a18c0e957.fritz.box (p4FE9D004.dip0.t-ipconnect.de. [79.233.208.4]) by smtp.gmail.com with ESMTPSA id r4sm11488123wia.19.2015.10.18.09.37.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Oct 2015 09:37:12 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: <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> <20151018160651.GA63497@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: Add VIEW_CONVERT_EXPR to operand_equal_p From: Richard Biener Date: Sun, 18 Oct 2015 17:14:00 -0000 To: Jan Hubicka ,Eric Botcazou CC: gcc-patches@gcc.gnu.org Message-ID: <9D70ECF7-CCB9-4D4E-955F-AD66BE7B22E3@gmail.com> X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg01685.txt.bz2 On October 18, 2015 6:06:51 PM GMT+02:00, Jan Hubicka wrote: >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? Adding back the mode check is fine if all types with the same TYPE_CANONICAL have the same mode. Otherwise we'd regress here. I thought we do for Struct x { int i; }; Typedef y x __attribute__((packed)); And then doing X x; Y y; X = y; Richard. >Honza >> >> -- >> Eric Botcazou