From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121258 invoked by alias); 16 Nov 2015 23:00:10 -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 121245 invoked by uid 89); 16 Nov 2015 23:00:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS 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, 16 Nov 2015 23:00:04 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id A7E618E22F; Mon, 16 Nov 2015 23:00:02 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-72.phx2.redhat.com [10.3.113.72]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAGN01CL002975; Mon, 16 Nov 2015 18:00:02 -0500 Subject: Re: [RFC, Patch]: Optimized changes in the register used inside loop for LICM and IVOPTS. To: Ajit Kumar Agarwal , GCC Patches References: <37378DC5BCD0EE48BA4B082E0B55DFAA4299E44D@XAP-PVEXMBX02.xlnx.xilinx.com> <56457FA0.1070201@redhat.com> <37378DC5BCD0EE48BA4B082E0B55DFAA429B45DD@XAP-PVEXMBX02.xlnx.xilinx.com> Cc: Vinod Kathail , Shail Aditya Gupta , Vidhumouli Hunsigida , Nagaraju Mekala From: Jeff Law Message-ID: <564A5FF1.6040108@redhat.com> Date: Mon, 16 Nov 2015 23:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <37378DC5BCD0EE48BA4B082E0B55DFAA429B45DD@XAP-PVEXMBX02.xlnx.xilinx.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg02007.txt.bz2 On 11/16/2015 10:36 AM, Ajit Kumar Agarwal wrote: >> For Induction variable optimization on tree SSA representation, the >> register used logic is based on the number of phi nodes at the loop >> header to represent the liveness at the loop. Current Logic used only >> the number of phi nodes at the loop header. Changes are made to >> represent the phi operands also live at the loop. Thus number of phi >> operands also gets incremented in the number of registers used. But my question is why is the # of PHI operands useful here. You'd have a stronger argument if it was the number of unique operands in each PHI. While I don't doubt this patch improved things, I think it's just putting a band-aid over the problem. I think anything that just looks at PHIs or at register liveness at loop boundaries is inherently underestimating the register pressure implications of code motion from inside to outside a loop. If an object is pulled out of the loop, then it's going to conflict with nearly every object that births in the loop (because the object being moved now has to live throughout the loop). There's exceptions, but I doubt they matter in practice. The object is also going to conflict with anything else that is live through the loop. At least that's how it seems to me at first thought. So build the set of objects (SSA_NAMEs) that either birth or are live through the loop that have the same type class as the object we want to hoist out of the loop (scalar, floating point, vector). Use that set of objects to estimate register pressure. It won't be exact because some of those objects could end up coloring the same. BUt it's probably still considerably more accurate than what we have now. I suspect that would be a better estimator for register pressure as far as LICM is concerned. jeff