From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77698 invoked by alias); 19 Oct 2015 20:47:37 -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 77687 invoked by uid 89); 19 Oct 2015 20:47:36 -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,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; Mon, 19 Oct 2015 20:47:34 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 78F0B542FA9; Mon, 19 Oct 2015 22:47:31 +0200 (CEST) Date: Mon, 19 Oct 2015 21:01:00 -0000 From: Jan Hubicka To: Richard Biener Cc: Jan Hubicka , Eric Botcazou , GCC Patches Subject: Re: Add VIEW_CONVERT_EXPR to operand_equal_p Message-ID: <20151019204731.GA27337@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> <20151018171448.GC63497@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-10/txt/msg01798.txt.bz2 Richard, I missed your reply earlier today. > > 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. > > Incomplete have VOIDmode, right? Yes > > > 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. > > Ok, so given we seem to be fine in practive with TYPE_MODE (type) == > TYPE_MODE (TYPE_CANONICAL (type)) Witht the exception of incopmlete variants a type. Then TYPE_CANONICAL may be complete and !VOIDmode. But sure, i believe we ought to chase away the calls to useless_type_conversion when one of types in incomplete. > (whether that's a but or not ...) I'm fine with re-instantiating the > mode check for > aggregate types. Please do that with > > Index: gcc/gimple-expr.c > =================================================================== > --- gcc/gimple-expr.c (revision 228963) > +++ gcc/gimple-expr.c (working copy) > @@ -89,8 +89,7 @@ useless_type_conversion_p (tree outer_ty > > /* Changes in machine mode are never useless conversions unless we > deal with aggregate types in which case we defer to later checks. */ > - if (TYPE_MODE (inner_type) != TYPE_MODE (outer_type) > - && !AGGREGATE_TYPE_P (inner_type)) > + if (TYPE_MODE (inner_type) != TYPE_MODE (outer_type)) > return false; OK, that is variant of the patch I had at beggining. I will test it. > > /* If both the inner and outer types are integral types, then the > > Can we asses equal sizes when modes are non-BLKmode then? Thus > > @@ -270,10 +269,9 @@ useless_type_conversion_p (tree outer_ty > use the types in move operations. */ > else if (AGGREGATE_TYPE_P (inner_type) > && TREE_CODE (inner_type) == TREE_CODE (outer_type)) > - return (!TYPE_SIZE (outer_type) > - || (TYPE_SIZE (inner_type) > - && operand_equal_p (TYPE_SIZE (inner_type), > - TYPE_SIZE (outer_type), 0))); > + return (TYPE_MODE (outer_type) != BLKmode > + || operand_equal_p (TYPE_SIZE (inner_type), > + TYPE_SIZE (outer_type), 0)); > > else if (TREE_CODE (inner_type) == OFFSET_TYPE > && TREE_CODE (outer_type) == OFFSET_TYPE) > > ? Hoping for VOIDmode incomplete case. Don't see why this would be a problem either. I am going to start the testing of this variant. Honza > > Richard. > > > Honza > >> > >> Richard. > >> > >> > >> >Honza > >> >> > >> >> -- > >> >> Eric Botcazou > >>