From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87474 invoked by alias); 12 Oct 2017 00:15:10 -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 87436 invoked by uid 89); 12 Oct 2017 00:15:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=scary, story, practices 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; Thu, 12 Oct 2017 00:15:06 +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 v9C0F15K010752; Wed, 11 Oct 2017 19:15:02 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id v9C0F1gD010749; Wed, 11 Oct 2017 19:15:01 -0500 Date: Thu, 12 Oct 2017 02:21:00 -0000 From: Segher Boessenkool To: Sandra Loosemore Cc: gcc-patches@gcc.gnu.org, law@redhat.com Subject: Re: [PATCH 3/3] Add targetm.insn_cost hook Message-ID: <20171012001500.GS4406@gate.crashing.org> References: <59DEABAD.6030603@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59DEABAD.6030603@codesourcery.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00718.txt.bz2 Hi! On Wed, Oct 11, 2017 at 05:39:25PM -0600, Sandra Loosemore wrote: > On 10/09/2017 01:35 PM, Segher Boessenkool wrote: > >This adds a new hook that the insn_cost function uses if a target has > >implemented it (it uses the old pattern_cost nee insn_rtx_cost if not). > As a target maintainer, I'm kind of confused by this patch, and I don't > think the tm.texi change gives sufficient guidance about the default > hook behavior, how it interacts with TARGET_RTX_COSTS and/or > TARGET_ADDRESS_COST, or the different contexts the three hooks are used > in. Do target maintainers need to do something to define this new hook > to prevent performance regressions? No, everything works as it did if you don't do anything. Should I add a little bit of documentation what the hook does by default? It may be good as a scary story, to get more ports to use their own hook implementation instead ;-) > I could try to write up some advice about cost models and tuning for the > internals manual, but at present I don't feel like I have any > understanding of what motivated this change or how it changed the > recommended practices for back end tuning. :-( insn_rtx_cost did not work with instructions: it worked with instruction _patterns_. It also does not work for anything but single-set and similar patterns (not the same as single_set, that requires an instruction!) It also is really hard to write a TARGET_RTX_COSTS that properly describes the cost of the machine instructions you have (and to keep it updated!) With these patches combine can make better decisions already (no longer do many instructions have "unknown" cost). I am planning to move more users of TARGET_RTX_COSTS over to insn_cost, or even get the needed info in a more direct way. This will take time; all help is welcome :-) Segher