From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36405 invoked by alias); 17 Sep 2015 16:56:00 -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 36377 invoked by uid 89); 17 Sep 2015 16:55:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 17 Sep 2015 16:55:59 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id E5CD98E6E1; Thu, 17 Sep 2015 16:55:57 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-28.phx2.redhat.com [10.3.113.28]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8HGtvDC009464; Thu, 17 Sep 2015 12:55:57 -0400 Subject: Re: [PATCH] Target hook for disabling the delay slot filler. To: Simon Dardis , Bernd Schmidt References: <55F82ADF.2030905@redhat.com> <55F832CF.2010406@redhat.com> Cc: "gcc-patches@gcc.gnu.org" From: Jeff Law Message-ID: <55FAF09D.3020005@redhat.com> Date: Thu, 17 Sep 2015 17:01:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg01317.txt.bz2 On 09/17/2015 03:52 AM, Simon Dardis wrote: > The profitability of using an ordinary branch over a delay slot branch > depends on how the delay slot is filled. If a delay slot can be filled from > an instruction preceding the branch or instructions proceeding that must be > executed on both sides then it is profitable to use a delay slot branch. Agreed. It's an over-simplification, but for the purposes of this discussion it's close enough. > > For cases when instructions are chosen from one side of the branch, > the proposed optimization strategy is to not speculatively execute > instructions when ordinary branches could be used. Performance-wise > this avoids executing instructions which the eager delay filler picked > wrongly. Are you trying to say that you have the option as to what kind of branch to use? ie, "ordinary", presumably without a delay slot or one with a delay slot? Is the "ordinary" actually just a nullified delay slot or some form of likely/not likely static hint? > > Since most branches have a compact form disabling the eager delay filler > should be no worse than altering it not to fill delay slots in this case. But what is the compact form at the micro-architectural level? My mips-fu has diminished greatly, but my recollection is the bubble is always there. Is that not the case? fill_eager_delay_slots is most definitely speculative and its profitability is largely dependent on the cost of what insns it finds to fill those delay slots and whether they're from the common or uncommon path. If it is able to find insns from the commonly executed path that don't have a long latency, then the fill is usually profitable (since the pipeline bubble always exists). However, pulling a long latency instruction (say anything that might cache miss or an fdiv/fsqrt) off the slow path and conditionally nullifying it can be *awful*. Everything else is in-between. Jeff