From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117300 invoked by alias); 27 Jan 2017 22:17:47 -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 117266 invoked by uid 89); 27 Jan 2017 22:17:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2289, rates 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 ESMTP; Fri, 27 Jan 2017 22:17:45 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7792B85542; Fri, 27 Jan 2017 22:17:45 +0000 (UTC) Received: from localhost.localdomain (ovpn-117-119.rdu2.redhat.com [10.10.117.119]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0RMHipU004586; Fri, 27 Jan 2017 17:17:44 -0500 Subject: Re: [RFC] sched: Do not move expensive insns speculatively (PR68664) To: Segher Boessenkool References: <9a0c95d7ab2d7c5532b51b898acae2ef8f756aa9.1485477070.git.segher@kernel.crashing.org> <20170127123851.GC30284@gate.crashing.org> <20170127141930.GF30284@gate.crashing.org> <20170127220154.GJ30284@gate.crashing.org> Cc: Richard Biener , GCC Patches From: Jeff Law Message-ID: Date: Fri, 27 Jan 2017 22:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170127220154.GJ30284@gate.crashing.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg02215.txt.bz2 On 01/27/2017 03:01 PM, Segher Boessenkool wrote: > On Fri, Jan 27, 2017 at 11:04:42AM -0700, Jeff Law wrote: >>> Well, the only thing from the pipeline description that is used here is >>> the insn latency, which isn't all that much higher than "normal" FP insns. >>> And simply "not decribed properly" won't do much good -- if we could >>> (without blowing up the automata) we would, and sched-rgn would then >>> still speculate this. >> And I think this is the core of the issue. We have multiple ports that >> don't necessarily fully describe the latency, issue rates, etc of >> certain insns like div/sqrt/rsqrt. There are good reasons for doing that. >> >> Because of the partial description, the scheduler may think those insns >> fit into a pipeline bubble within the loop, when reality they do not. >> >> The scheduler currently has no way of knowing what insns have this >> property. While there are cases where we'd like to speculate a div or >> sqrt to give it more time to complete without stalls -- there's no good >> way to do that without fully describing them to the scheduler. >> >> My preference would be somehow either mark those insns as not fully >> modeled and avoid speculating on them. Or invent a target hook to allow >> the scheduler to query the backend. > > This is my preference -- have it in one location, not spread out over > many instruction patterns, or many scheduling descriptions. No strong opinions on the two approaches. I could easily see defining a hook and ports implementing the hook via attributes if that were easier for them. Other ports might implement the hook by scanning the insn for key RTL codes. > >> Note that these could be used elsewhere -- for example delay slot >> scheduling and predication. Delay slot scheduling does speculation and >> there's ports that simply refuse to allow certain instructions (div/sqrt >> on one port, I think all FP stuff on another) to avoid these kinds of >> problems. > > Are you saying there already is a hook we could use, maybe after > adjusting it a bit? That would be ideal. No -- ports handle this inside there eligible_for_delay_XXX support. It's not something that could be reasonably re-used within the scheduler. Jeff