From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98945 invoked by alias); 27 Jan 2017 01:19:21 -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 98931 invoked by uid 89); 27 Jan 2017 01:19:20 -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=Scheduling, H*f:sk:9a0c95d, H*i:sk:Sn1nWXo, H*f:sk:JzYF6Qw 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 01:19:10 +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 v0R1J72b024057; Thu, 26 Jan 2017 19:19:07 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id v0R1J6Y0024052; Thu, 26 Jan 2017 19:19:06 -0600 Date: Fri, 27 Jan 2017 01:27:00 -0000 From: Segher Boessenkool To: Andrew Pinski Cc: GCC Patches Subject: Re: [RFC] sched: Do not move expensive insns speculatively (PR68664) Message-ID: <20170127011905.GA30284@gate.crashing.org> References: <9a0c95d7ab2d7c5532b51b898acae2ef8f756aa9.1485477070.git.segher@kernel.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/msg02106.txt.bz2 On Thu, Jan 26, 2017 at 05:00:44PM -0800, Andrew Pinski wrote: > On Thu, Jan 26, 2017 at 4:38 PM, Segher Boessenkool > wrote: > > Scheduling should never move very expensive instructions to places they > > are executed more frequently. This patch fixes that, reducing the > > execution time of c-ray by over 40% (I tested on a BE Power7 system). > > > > Is there some existing way to test for "very expensive insn" or "very > > expensive insn we should not speculate"? Should there be a new hook? > > Is only disallowing (FP) SQRT and DIV a good solution? > > Seems like it should be checking the insn cost and compare that > against some parameter. That is possibly set by the target if needed. But what is "insn cost"? Latency is no good at all -- we *want* insns with higher latency to be earlier. fsqrt is not pipelined, and that is what makes it so costly. (This isn't modeled in the scheduling description btw: that would make the automata sizes explode, the usual problem). Segher