From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113645 invoked by alias); 3 Apr 2015 13:30:44 -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 113635 invoked by uid 89); 3 Apr 2015 13:30:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.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; Fri, 03 Apr 2015 13:30:43 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 847F02B64AA; Fri, 3 Apr 2015 13:30:41 +0000 (UTC) Received: from freie.home (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t33DUcB4012198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Apr 2015 09:30:40 -0400 Received: from livre.home (livre.home [172.31.160.2]) by freie.home (8.14.8/8.14.8) with ESMTP id t33DSVQB017607; Fri, 3 Apr 2015 10:28:32 -0300 From: Alexandre Oliva To: Richard Biener Cc: GCC Patches Subject: Re: [PR64164] drop copyrename, integrate into expand References: Date: Fri, 03 Apr 2015 13:30:00 -0000 In-Reply-To: (Richard Biener's message of "Tue, 31 Mar 2015 16:06:27 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2015-04/txt/msg00118.txt.bz2 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. > 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. >> + 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. > 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. > So the above does full coalescing ignoring conflicts. Yeah. We want to tell what we'd get if all coalesce possibilities are taken, so that we can assign the same basevar to all partitions so that we detect conflicts. > Did you do any statistics on how the number of basevars changes with your patch > compared to trunk? 'fraid I didn't run any statistics whatsoever. I didn't think it was important, since it's pretty much just doing copyrename during coalesce. Truth be told, this has since relaxed some of the constraints from copyrename, and I'm going to relax some more in the next iteration, so I 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? -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer