From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118612 invoked by alias); 5 Aug 2015 00:39:24 -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 118595 invoked by uid 89); 5 Aug 2015 00:39:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no 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; Wed, 05 Aug 2015 00:39:21 +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 A1CB38E3D0; Wed, 5 Aug 2015 00:39:20 +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 t750d9E1000786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Aug 2015 20:39:19 -0400 Received: from livre.home (livre.home [172.31.160.2]) by freie.home (8.14.8/8.14.8) with ESMTP id t750cmD5015854; Tue, 4 Aug 2015 21:38:49 -0300 From: Alexandre Oliva To: Richard Biener Cc: "H.J. Lu" , Segher Boessenkool , Jeff Law , GCC Patches , Christophe Lyon , David Edelsohn , Eric Botcazou Subject: Re: [PR64164] drop copyrename, integrate into expand References: <20150723203112.GB27818@gate.crashing.org> Date: Wed, 05 Aug 2015 00:39:00 -0000 In-Reply-To: (Richard Biener's message of "Tue, 4 Aug 2015 11:48:03 +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-08/txt/msg00227.txt.bz2 On Aug 4, 2015, Richard Biener wrote: > Though I wonder on whether splitting the patch into a first one with disabling > coalescing of parms (their default defs(?)) and a followup implementing the > support for that. We can't disable coalescing of parms altogether. With -O0, we must coalesce all SSA_NAMEs referencing each parm to a single partition. With optimization, we could coalesce parms in general, just not these special cases in which the parm is to live in a caller-supplied memory block. Now, it's not coalescing parms proper that brought so much risk to the patch, it is assigning rtl to SSA partitions, and having assign_parms* use that assignment. Considering that sometimes a single param necessarily ends up in more than one partition, requiring two assignments, and that assign_parms* can't deal with that, I don't see how to easily disable the cfgexpand logic when it comes to parms, so as to be able to leave assign_parms alone. How about, if further problems arise that justify reverting the patch one more time, I'll look into splitting the patch as you suggested, but otherwise, I'll save myself the trouble, ok? > So - is my observation correct that this is only about coalescing of the > default defs of parameters, not other SSA names based on parameter decls? It's more like the opposite, i.e., we *refrain* from coalescing other SSA_NAMEs related with byref params, so that we can easily tell when a partition references a byref param and whether that partition holds its default def. We could have coalesced any other names that ended up in different partitions, and even the partition holding the default def, if we had other means to identify partitions with default defs of byref params. For example, we could create a bitmap of byref param default def versions, and then, after partitioning, map those to the partitions they were assigned to. In fact, I might do that as a followup. > Do you think this splitting is feasible and my concern about the > code-gen issues warranted? It is feasible but not exactly easy. As for codegen, I hope to have covered all cases now, but should we find out I haven't, I'll try the split and see what that gets us. Did you have any special cases in mind that it looks like I may have missed? Thanks, -- 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