From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14551 invoked by alias); 27 Jan 2017 22:29:39 -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 14540 invoked by uid 89); 27 Jan 2017 22:29:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=Hx-languages-length:1332, H*MI:sk:c186c35, H*i:sk:c186c35, H*f:sk:c186c35 X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Jan 2017 22:29:36 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id v0RMTV75031350; Fri, 27 Jan 2017 16:29:31 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id v0RMTUav031346; Fri, 27 Jan 2017 16:29:30 -0600 Date: Fri, 27 Jan 2017 22:30:00 -0000 From: Segher Boessenkool To: Jeff Law Cc: Richard Biener , GCC Patches Subject: Re: [RFC] sched: Do not move expensive insns speculatively (PR68664) Message-ID: <20170127222928.GL30284@gate.crashing.org> References: <9a0c95d7ab2d7c5532b51b898acae2ef8f756aa9.1485477070.git.segher@kernel.crashing.org> <20170127123851.GC30284@gate.crashing.org> <20170127141930.GF30284@gate.crashing.org> <20170127220154.GJ30284@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg02217.txt.bz2 On Fri, Jan 27, 2017 at 03:17:42PM -0700, Jeff Law wrote: > >>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. Okay, I'll come up with something. > >>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. Too bad. Oh well. Segher