From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18700 invoked by alias); 30 Aug 2013 09:50:21 -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 18688 invoked by uid 89); 30 Aug 2013 09:50:21 -0000 Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com) (74.125.82.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 30 Aug 2013 09:50:21 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,NO_RELAYS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f50.google.com Received: by mail-wg0-f50.google.com with SMTP id m14so1394651wgh.29 for ; Fri, 30 Aug 2013 02:50:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.126.69 with SMTP id mw5mr1494442wib.59.1377856217971; Fri, 30 Aug 2013 02:50:17 -0700 (PDT) Received: by 10.194.200.74 with HTTP; Fri, 30 Aug 2013 02:50:17 -0700 (PDT) In-Reply-To: <51B89C27.6020507@redhat.com> References: <51B178BA.1000802@redhat.com> <51B89C27.6020507@redhat.com> Date: Fri, 30 Aug 2013 10:06:00 -0000 Message-ID: Subject: Re: Improve uncprop and coalescing From: Richard Biener To: Jeff Law Cc: gcc-patches Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-08/txt/msg01855.txt.bz2 On Wed, Jun 12, 2013 at 6:04 PM, Jeff Law wrote: > > On 06/07/13 03:14, Richard Biener wrote: > >>> +/* Given SSA_NAMEs NAME1 and NAME2, return true if they are candidates >>> for >>> + coalescing together, false otherwise. >>> + >>> + This must stay consistent with the code in tree-ssa-live.c which >>> + sets up base values in the var map. */ >>> + >>> +bool >>> +gimple_can_coalesce_p (tree name1, tree name2) >>> +{ >>> + /* First check the SSA_NAME's associated DECL. We only want to >>> + coalesce if they have the same DECL or both have no associated >>> DECL. >>> */ >>> + if (SSA_NAME_VAR (name1) != SSA_NAME_VAR (name2)) >>> + return false; >>> + >>> + /* Now check the types. If the types are the same, then we should >>> + try to coalesce V1 and V2. */ >>> + tree t1 = TREE_TYPE (name1); >>> + tree t2 = TREE_TYPE (name2); >>> + if (t1 == t2) >>> + return true; >>> + >>> + /* If the types are not the same, check for a canonical type match. >>> This >>> + (for example) allows coalescing when the types are fundamentally >>> the >>> + same, but just have different names. */ >>> + if (TYPE_CANONICAL (t1) && TYPE_CANONICAL (t1) == TYPE_CANONICAL (t2)) >> >> >> Please use types_compatible_p (t1, t2) here, that's the correct API to use >> here. >> >>> + return true; >>> + >>> + return false; >>> +} >>> diff --git a/gcc/tree-ssa-live.c b/gcc/tree-ssa-live.c >>> index 83a52a0..a624d00 100644 >>> --- a/gcc/tree-ssa-live.c >>> +++ b/gcc/tree-ssa-live.c >>> @@ -111,8 +111,12 @@ var_map_base_init (var_map map) >>> as it restricts the sets we compute conflicts for. >>> Using TREE_TYPE to generate sets is the easies as >>> type equivalency also holds for SSA names with the same >>> - underlying decl. */ >>> - m->base.from = TREE_TYPE (var); >>> + underlying decl. >>> + >>> + Check gimple_can_coalesce_p when changing this code. */ >>> + m->base.from = (TYPE_CANONICAL (TREE_TYPE (var)) >>> + ? TYPE_CANONICAL (TREE_TYPE (var)) >>> + : TREE_TYPE (var)); >> >> >> eh, but it's made complicated here ... so above do >> >> >> if (TYPE_CANONICAL (t1) && TYPE_CANONICAL (t1) == TYPE_CANONICAL (t2) >> && types_compatible_p (t1, t2)) >> >> because looking at useless_type_conversion_p it looks like pointer types >> with different address-spaces may have the same canonical type. A comment >> on why we check both, refering to var_map_base_init should also be added. > > Reading this again after a night of sleep, it appears you're agreeing that > we can't just use types_compatible_p to drive what objects are put on the > coalesce list. The only code change you're asking for is to make sure we > properly reject pointer types with different address spaces (which can be > done via types_compatible_p). > > > Right? Yes, if I remember correctly after this long time ;) Richard. > jeff > >