From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41688 invoked by alias); 6 Apr 2015 15:57:45 -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 41645 invoked by uid 89); 6 Apr 2015 15:57:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 06 Apr 2015 15:57:43 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 754248E748; Mon, 6 Apr 2015 15:57:41 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-31.phx2.redhat.com [10.3.113.31]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t36FveSP007597; Mon, 6 Apr 2015 11:57:41 -0400 Message-ID: <5522ACF4.9000101@redhat.com> Date: Mon, 06 Apr 2015 15:57:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Alexandre Oliva , Richard Biener CC: GCC Patches Subject: Re: [PR64164] drop copyrename, integrate into expand References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00197.txt.bz2 On 04/03/2015 07:28 AM, Alexandre Oliva wrote: > On Mar 31, 2015, Richard Biener wrote: > >>> + || !(SSA_NAME_IS_DEFAULT_DEF (var) >>> + || (param_defaults >>> + && bitmap_bit_p (param_defaults, part)))) > >> This looks somewhat awkward to me ;) Is it really important to allow >> coalescing PARM_DECL-based SSA vars with sth else? > > It's a valid optimization. I can't say it's really important, but if > the only objection is to param_defaults, I'm getting rid of it. I doubt it's terribly important, but I agree it's a valid optimization. Do you have a testcase where it triggers? Can we include that too so that if someone wants to remove this later for some reason or another we'd at least have a chance of seeing a regression. ISTM it can only trigger when the PARM is tied to another object via a copy and the PARM and other object have non-overlapping lifetimes. I'd expect that this may happen at PHIs where the PARM appears on the RHS and dies at that point -- the PARM and the PHI result are likely not going to conflict and thus may coalesce. > >> At least abnormal coalescing doesn't need to do that, so just walking >> over the function decls parameters and making their default-def live >> should be enough? > > It should. We'd have to duplicate logic of parameters, including static > chain and whatnot. I figured this would make it more resilient to > changes elsewhere. This ties in a bit to my comment about whether or not we've got proper life information for PARMs. I'd generally prefer to see us get the life information corrrect. > >>> + else if (TREE_CODE (SSA_NAME_VAR (var2)) == VAR_DECL) >>> + leader = SSA_NAME_VAR (var2); >>> + else /* What else could it be? */ >>> + gcc_unreachable (); >>> + > >> definitely comments missing in this spaghetti... > > I'm trying to remove the spaghetting now. Good :-) > >> or seeing this, why coalesce default-defs at all? > > Why not? (the referenced code is gone from my local tree, BTW) > >> Either they are param values or they have indetermined values (and >> thus we can and do pick whatever is available at expansion time)? > > If they are param values, we want to have them available; if they > aren't, whatever we coalesce with is good. Agreed. Didn't we recently change the coalescing code to allow coalescing non-PARM default defs more aggressively: Author: glisse Date: Mon Nov 3 10:47:04 2014 +0000 2014-11-03 Marc Glisse PR tree-optimization/60770 gcc/ * tree-into-ssa.c (rewrite_update_stmt): Return whether the statement should be removed. (maybe_register_def): Likewise. Replace clobbers with default definitions. (rewrite_dom_walker::before_dom_children): Remove statement if rewrite_update_stmt says so. * tree-ssa-live.c: Include tree-ssa.h. (set_var_live_on_entry): Do not mark undefined variables as live. (verify_live_on_entry): Do not check undefined variables. * tree-ssa.h (ssa_undefined_value_p): New parameter for the case of partially undefined variables. * tree-ssa.c (ssa_undefined_value_p): Likewise. (execute_update_addresses_taken): Do not drop clobbers. gcc/testsuite/ * gcc.dg/tree-ssa/pr60770-1.c: New file. > guess some statistics wouldn't be a bad idea. Is there any specific > testcase you're interested in, or something like a GCC bootstrap or > somesuch? Not from me. bootstrap or .i files from gcc bootstrap would seem to be sufficient to me. jeff