From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72137 invoked by alias); 6 Apr 2015 16:08:23 -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 72122 invoked by uid 89); 6 Apr 2015 16:08:22 -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 16:08:21 +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 7A0668EA28 for ; Mon, 6 Apr 2015 16:08:20 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-31.phx2.redhat.com [10.3.113.31]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t36G8JGU030219; Mon, 6 Apr 2015 12:08:20 -0400 Message-ID: <5522AF73.5000706@redhat.com> Date: Mon, 06 Apr 2015 16:08: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 CC: gcc-patches@gcc.gnu.org Subject: Re: [PR64164] drop copyrename, integrate into expand References: <551A2C7C.8060005@redhat.com> 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/msg00198.txt.bz2 On 04/03/2015 07:17 AM, Alexandre Oliva wrote: >>> @@ -890,6 +900,36 @@ build_ssa_conflict_graph (tree_live_info_p liveinfo) >>> live_track_process_def (live, result, graph); >>> } >>> >>> + /* Pretend there are defs for params' default defs at the start >>> + of the (post-)entry block. We run after abnormal coalescing, >>> + so we can't assume the leader variable is the default >>> + definition, but because of SSA_NAME_VAR adjustments in >>> + attempt_coalesce, we can assume that if there is any >>> + PARM_DECL in the partition, it will be the leader's >>> + SSA_NAME_VAR. */ > > This comment is outdated. Since we no longer have abnormal coalescing > before building the conflict graph, we can just test whether each > SSA_NAME is a default def for a PARM_DECL and be done with it. OK. Please update the comment :-0 > >> So the issue here is you want to iterate over the objects live at the >> entry block, which would include any SSA_NAMEs which result from >> PARM_DECLs. I don't guess there's an easier way to do that other than >> iterating over everything live in that initial block? > > We could iterate over all SSA_NAMEs, but that would probably be more > costly. There shouldn't be very many live variables at the function > entry, so using the live bitmaps is likely to save us time, especially > on functions with lots of SSA_NAMEs. Agreed. Iterating over the SSA_NAMEs was what came to mind when I pondered this a bit more and I'd rejected it for the same reason. Can we get to the SSA_NAMEs associated with the PARM_DECLs from the function decl? I can't think of a way off the top of my head, but if we could, then that'd avoid the iteration over the bitmap of live variables. But then again, the bitmap of live variables ought to be small, particularly if we're not marking non-PARM default defs as live anymore (see patch reference in my prior message). >> So the bulk of the changes into this routine are really about picking >> a good leader, which presumably is how we're able to get the desired >> effects on debuginfo that we used to get from tree-ssa-copyrename.c? > > This has nothing to do with debuginfo, I'm afraid. We just had to keep > track of parm and result decls to avoid coalescing them together, and > parm decl default defs to promote them to leaders, because expand copies > incoming REGs to pseudos in PARM_DECL's DECL_RTL. We should fill that > in with the RTL created for the default def for the PARM_DECL. At the > end, I believe we also copy the RESULT_DECL DECL_RTL to the actual > return register or rtl. I didn't want to tackle the reworking of these > expanders to avoid problems out of copying incoming parms to one pseudo > and then reading it from another, as I observed before I made this > change. I'm now tackling that, so that we can refrain from touching the > base vars altogether, and not refrain from coalescing parms and results. Hmmm, so the real issue here is the expansion setup of parms and results. I hadn't pondered that aspect. I'd encourage fixing the expansion code too if you can see a path for that. Basically I just don't like special casing things like this -- coalescing should be driven by life information/conflict graph and a copy relationship between the two candidate objects. Overall it looks like you're on the right path and we'll just need to iterate a bit more. jeff