From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52565 invoked by alias); 18 Oct 2015 17:14:55 -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 52548 invoked by uid 89); 18 Oct 2015 17:14:54 -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 17:14:52 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 4977354113A; Sun, 18 Oct 2015 19:14:48 +0200 (CEST) Date: Sun, 18 Oct 2015 18:45:00 -0000 From: Jan Hubicka To: Richard Biener Cc: Jan Hubicka , Eric Botcazou , gcc-patches@gcc.gnu.org Subject: Re: Add VIEW_CONVERT_EXPR to operand_equal_p Message-ID: <20151018171448.GC63497@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> <9D70ECF7-CCB9-4D4E-955F-AD66BE7B22E3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9D70ECF7-CCB9-4D4E-955F-AD66BE7B22E3@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-10/txt/msg01686.txt.bz2 > > 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; Do you have any idea how to turn this into a testcase? I don't think we could add packed attribute to typedef. Even in gimple_canonical_types_compatible_p /* Can't be the same type if they have different mode. */ if (TYPE_MODE (t1) != TYPE_MODE (t2)) return false; (which IMO may be wrong WRT -mavx flags where modes of same types may be different in different TUs) Therefore I would say that TYPE_CANONICAL determine mode modulo the fact that incoplete variant of a complete type will have VOIDmode instead of complete type's mode (during non-LTO). That is why I allow mode changes for casts from complete to incomplete. In longer run I think that every query to useless_type_conversion_p that contains incomplete types is a confused query. useless_type_conversion_p is about operations on the value and there are no operations for incomplete type (and function types). I know that ipa-icf-gimple and the following code in gimplify-stmt checks this frequently: /* The FEs may end up building ADDR_EXPRs early on a decl with an incomplete type. Re-build ADDR_EXPRs in canonical form here. */ if (!types_compatible_p (TREE_TYPE (op0), TREE_TYPE (TREE_TYPE (expr)))) *expr_p = build_fold_addr_expr (op0); Taking address of incomplete type or functions, naturally, makes sense. We may want to check something else here, like simply TREE_TYPE (op0) != TREE_TYPE (TREE_TYPE (expr)) and once ipa-icf is cleanded up start sanity checking in usless_type_conversion that we use it to force equality only on types that do have values. We also can trip it when checking TYPE_METHOD_BASETYPE which may be incomplete. This is in the code checking useless_type_conversion on functions that I think are confused querries anyway - we need the ABI matcher, I am looking into that. Honza > > Richard. > > > >Honza > >> > >> -- > >> Eric Botcazou >