From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15929 invoked by alias); 18 May 2017 10:41:17 -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 15918 invoked by uid 89); 18 May 2017 10:41:16 -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,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*f:sk:N4ruXqS, bin.cheng, U*amker.cheng, H*f:sk:87fug3b X-HELO: mail-wm0-f44.google.com Received: from mail-wm0-f44.google.com (HELO mail-wm0-f44.google.com) (74.125.82.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 18 May 2017 10:41:14 +0000 Received: by mail-wm0-f44.google.com with SMTP id d127so47380424wmf.0 for ; Thu, 18 May 2017 03:41:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version; bh=/BHf2AAldrqoOEU8nVAKtgn/B3Ge4Eh4bt9JHf1OHpk=; b=oe3v2LAyMx+YftalpjllPer6he90TQN0lbjAmwDY+F4fyLy5HaY/qyKKROmD+G47IQ 85hx7n3J3rSpo0J7xsdMpDFeuaNAZHA8GOAKj/wcx/Qdqkpp8/OBnnq6Z0jm8i4Tzgj0 gS88WFZovudhy39grAFSRHCpGA17A12YQvYfFmQvoHQAWIeVsoKnXKKlbr+PfAq6aavE mFkzMN0BKSsG12BRaFXRc/yd0Zp26AML5wowPKaqpyRMJZHu/3POAB975n+Q4dbEF7ha VBNo/a7pXzRiWLvPRaB7WbmclXcx+O9YdTmoXKnRxZEkHFzAHWmL0i0S24Olkzl2/Re8 t10A== X-Gm-Message-State: AODbwcCcs4wcibbPrqDIRjGrs5Z7izNdM8trmreGxD59AXKWxvniuwUE 4nfJyBrOKayKSdWR X-Received: by 10.28.168.201 with SMTP id r192mr2458715wme.43.1495104075890; Thu, 18 May 2017 03:41:15 -0700 (PDT) Received: from localhost (188.29.164.129.threembb.co.uk. [188.29.164.129]) by smtp.gmail.com with ESMTPSA id m1sm5092121wme.7.2017.05.18.03.41.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 18 May 2017 03:41:14 -0700 (PDT) From: Richard Sandiford To: "Bin.Cheng" Mail-Followup-To: "Bin.Cheng" ,Richard Biener , "gcc-patches\@gcc.gnu.org" , richard.sandiford@linaro.org Cc: Richard Biener , "gcc-patches\@gcc.gnu.org" Subject: Re: [PATCH GCC8][29/33]New register pressure estimation References: <87fug3bqwm.fsf@linaro.org> Date: Thu, 18 May 2017 10:52:00 -0000 In-Reply-To: (Bin Cheng's message of "Thu, 18 May 2017 11:16:30 +0100") Message-ID: <87k25efnwb.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-05/txt/msg01447.txt.bz2 "Bin.Cheng" writes: > On Wed, May 17, 2017 at 1:37 PM, Richard Sandiford > wrote: >> "Bin.Cheng" writes: >>> -/* Calculates cost for having N_REGS registers. This number includes >>> - induction variables, invariant variables and invariant expressions. */ >>> +/* Estimate register pressure for loop having N_INVS invariants and N_CANDS >>> + induction variables. Note N_INVS includes both invariant variables and >>> + invariant expressions. */ >>> >>> static unsigned >>> -ivopts_global_cost_for_size (struct ivopts_data *data, unsigned n_regs) >>> +ivopts_estimate_reg_pressure (struct ivopts_data *data, unsigned n_invs, >>> + unsigned n_cands) >>> { >>> - unsigned cost = estimate_reg_pressure_cost (n_regs, >>> - data->regs_used, data->speed, >>> - data->body_includes_call); >>> - /* Add n_regs to the cost, so that we prefer eliminating ivs if >>> possible. */ >>> - return n_regs + cost; >>> + unsigned cost; >>> + unsigned n_old = data->regs_used, n_new = n_invs + n_cands; >>> + unsigned regs_needed = n_new + n_old, available_regs = target_avail_regs; >>> + bool speed = data->speed; >>> + >>> + /* If there is a call in the loop body, the call-clobbered registers >>> + are not available for loop invariants. */ >>> + if (data->body_includes_call) >>> + available_regs = available_regs - target_clobbered_regs; >>> + >>> + /* If we have enough registers. */ >>> + if (regs_needed + target_res_regs < available_regs) >>> + cost = n_new; >>> + /* If close to running out of registers, try to preserve them. */ >>> + else if (regs_needed <= available_regs) >>> + cost = target_reg_cost [speed] * regs_needed; >>> + /* If we run out of available registers but the number of candidates >>> + does not, we penalize extra registers using target_spill_cost. */ >>> + else if (n_cands <= available_regs) >>> + cost = target_reg_cost [speed] * available_regs >>> + + target_spill_cost [speed] * (regs_needed - available_regs); >>> + /* If the number of candidates runs out available registers, we penalize >>> + extra candidate registers using target_spill_cost * 2. Because it is >>> + more expensive to spill induction variable than invariant. */ >>> + else >>> + cost = target_reg_cost [speed] * available_regs >>> + + target_spill_cost [speed] * (n_cands - available_regs) * 2 >>> + + target_spill_cost [speed] * (regs_needed - n_cands); >>> + >>> + /* Finally, add the number of candidates, so that we prefer eliminating >>> + induction variables if possible. */ >>> + return cost + n_cands; >> >> It looks like the return is mixing units. Would it work to return >> a pair instead, and use lexicographical ordering? > Hi Richard, > It just penalizes the cost by the number of candidates, rather than > returns n_cands to caller. Actually that information is available all > the time in ivopts_data structure. Yeah, but what I meant was: "cost" seems to be measured in abstract instruction units, while "n_cands" counts a number of variables. It doesn't seem to make sense to add them together. If the idea is to use n_cands as a tie-breaker when the instruction costs are the same, then lexicographical ordering of pairs would give that without mixing the units. Thanks, Richard