From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20319 invoked by alias); 5 Aug 2015 09:14:57 -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 20310 invoked by uid 89); 5 Aug 2015 09:14:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-io0-f180.google.com Received: from mail-io0-f180.google.com (HELO mail-io0-f180.google.com) (209.85.223.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 05 Aug 2015 09:14:55 +0000 Received: by iodd187 with SMTP id d187so43040008iod.2 for ; Wed, 05 Aug 2015 02:14:54 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.137.154 with SMTP id t26mr9309180ioi.13.1438766093943; Wed, 05 Aug 2015 02:14:53 -0700 (PDT) Received: by 10.107.32.140 with HTTP; Wed, 5 Aug 2015 02:14:53 -0700 (PDT) In-Reply-To: References: <20150723203112.GB27818@gate.crashing.org> Date: Wed, 05 Aug 2015 09:14:00 -0000 Message-ID: Subject: Re: [PR64164] drop copyrename, integrate into expand From: Richard Biener To: Alexandre Oliva Cc: "H.J. Lu" , Segher Boessenkool , Jeff Law , GCC Patches , Christophe Lyon , David Edelsohn , Eric Botcazou Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00245.txt.bz2 On Wed, Aug 5, 2015 at 2:38 AM, Alexandre Oliva wrote: > 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? Sure. >> 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? It was just a hunch when you talked about BLKmode and params in memory. As coalescing is about SSA name (thus register) coalescing I was thinking that if you coalesce a register with incoming memory you'll end up with more memory accesses? But maybe I'm completely off here. I also thought of the RTL expansion thing we do with at first copying the hardreg incoming args to pseudos and how that interacts with coalescing. But I guess you have eyed code-gen changes a bit anyway. Thanks, Richard. > 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