From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35884 invoked by alias); 5 Aug 2015 23:03:25 -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 35143 invoked by uid 89); 5 Aug 2015 23:03:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,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 23:03:13 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 34B12F80ED; Wed, 5 Aug 2015 23:03:12 +0000 (UTC) Received: from freie.home (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t75N37MZ020112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Aug 2015 19:03:11 -0400 Received: from free (free-to-gw.home [172.31.160.17]) by freie.home (8.14.8/8.14.8) with ESMTP id t75N2oxw002822; Wed, 5 Aug 2015 20:02:51 -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 23:03:00 -0000 In-Reply-To: (Richard Biener's message of "Wed, 5 Aug 2015 11:14:53 +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/msg00320.txt.bz2 On Aug 5, 2015, Richard Biener wrote: > 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? Since we only coalesce variables whose promoted mode is the same, if one of them gets BLKmode and has to live in memory, so would all the others it might coalesce with. So, even though we have gimple_regs, we can't have pseudos. This was observed with vector types for which no native vector mode is available. It would still make sense to share them when possible, to reduce the number of mem-to-mem copies. And we don't want to copy incoming BLKmode parms to *another* memory location if we can help it. Now, maybe you're concerned about incoming parms passed by reference that *can* be held in pseudos. For those, we will perform a load from memory to a pseudo and use that, even if the pseudo ends up allocated in memory. > 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. Most of what changed now is who gets to choose the pseudo; it used to be assign_parms, now it's cfgexpand. The other significant change is that now, when cfgexpand detects a BLKmode parm, it will choose MEM, but it won't set up the address, so that assign_parms still does what it used to, namely, copy the incoming hard reg to a pseudo, and then use the pseudo as the MEM address. > But I guess you have eyed code-gen changes a bit anyway. Yeah. Not much has changed in the before parm_birth area; expected changes have to do with the pseudo numbering. IIRC, anything else would be unexpected. -- 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