From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12519 invoked by alias); 23 Oct 2014 03:29:51 -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 12497 invoked by uid 89); 23 Oct 2014 03:29:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f54.google.com Received: from mail-pa0-f54.google.com (HELO mail-pa0-f54.google.com) (209.85.220.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 23 Oct 2014 03:29:49 +0000 Received: by mail-pa0-f54.google.com with SMTP id rd3so245291pab.27 for ; Wed, 22 Oct 2014 20:29:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=cwfpuWWcnv35Hj4PnVRcBSoX0Egk7a6kB7zi0RDVEbI=; b=cRWmfts6pLy3r14SWvtr9Zy3UJPLukFIw1A3R3k6pB30T4eUkksRqtQybiZxzQZVVG jcigS+/JPPI7xZijWiRgmVm4CUHyi80lcmaG13dh19y3gEwJUQKxA/xcboeKWfEHAnmd yVEHEMMHEpaghFHpVx5ODQDO7dQqeFqDUfzMFAeotCgUSJtUCwzZNXrUj/jopUX3kux9 SkRJPYr8dfgVK/T4d0veiB2xRq7HzHkcGu51eHAOrVybXnz+lxyzitWKUD4TcXbq+C8d 7tYx3WaeRidDtMr3wNqGm6YHmqcCzhniCgmaUNSCMqlR2uhFmXUxs2oAzicCEW5rvNPl 6NOQ== X-Gm-Message-State: ALoCoQnyYCxmIuRYn4blIZKSKEvtAS2ATx67LqvNuamJbYMWRWt4ot+FnY7u7qY7E5ZqZWDpp3br X-Received: by 10.66.136.143 with SMTP id qa15mr2263924pab.90.1414034987880; Wed, 22 Oct 2014 20:29:47 -0700 (PDT) Received: from [192.168.0.122] (121-99-179-86.bng1.nct.orcon.net.nz. [121.99.179.86]) by mx.google.com with ESMTPSA id ic3sm397430pbc.26.2014.10.22.20.29.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 20:29:46 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [PATCH 3/8] Remove cached_first_cycle_multipass_dfa_lookahead and cached_issue_rate From: Maxim Kuvyrkov In-Reply-To: <5446815C.6050609@redhat.com> Date: Thu, 23 Oct 2014 03:34:00 -0000 Cc: gcc-patches@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5446815C.6050609@redhat.com> To: Vladimir Makarov X-SW-Source: 2014-10/txt/msg02327.txt.bz2 On Oct 22, 2014, at 4:53 AM, Vladimir Makarov wrote: > On 10/20/2014 11:16 PM, Maxim Kuvyrkov wrote: >> Hi, >>=20 >> This patch cleans up (removes) cached_first_cycle_multipass_dfa_lookahea= d and cached_issue_rate. >>=20 >> These seem to be an artifact from the scheduler refactoring 10+ years ag= o. They assume that dfa_lookahead and issue_rate can change mid-way throug= h scheduling, which is never the case. All backends currently treat dfa_lo= okahead and issue_rate as constants for the duration of scheduling passes. >>=20 >> Bootstrapped on x86_64-linux-gnu. Regression testing is in progress. O= K to commit if no regressions? >>=20 > Yes. the patch for issue rate itself is ok but you should have modified > doc/tm.texi too for dfa lookahead hook saying that it should be a > constant (issue rate already has such clause). >=20 > On the other hand I'd not assume that dfa look ahead is a constant. In > future we could make it non-constant to differentiate non-hot and hot > functions to speed up the scheduler as dfa look ahead scheduling is > pretty expensive. >=20 > So issue rate change is ok but I'd not rush to change dfa look ahead > related code. It is trivial to prove that currently cached_first_cycle_multipass_dfa_look= ahead always has the same value as dfa_lookahead. And, even should targetm= .sched.first_cycle_multipass_dfa_lookahead start returning different values= , max_issue will happily continue to use the value that the hook returned i= n sched_init(). Also, your suggestion to use different dfa_lookahead values for hot/cold fu= nctions is not affected by this patch. The values of dfa_lookahead variabl= e have scope of the scheduling pass, which is invoked separately for every = function. I guess, you could, potentially, start differentiating values of dfa_lookah= ead based on whether a basic_block is hot or cold, but handling this scenar= io would require significant changes throughout the scheduler. To summarize, dfa_lookahead is currently a pass-time invariant, that is fre= e to change between invocations of the scheduler pass. Cached_first_cycle_= multipass_dfa_lookahead always holds the same value as dfa_lookahead, and, = as such, is extraneous. Thank you, -- Maxim Kuvyrkov www.linaro.org