From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39310 invoked by alias); 1 Jul 2017 13:23:56 -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 39280 invoked by uid 89); 1 Jul 2017 13:23:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 01 Jul 2017 13:23:54 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 1495D5467DC; Sat, 1 Jul 2017 15:23:52 +0200 (CEST) Date: Sat, 01 Jul 2017 13:23:00 -0000 From: Jan Hubicka To: David Edelsohn Cc: Segher Boessenkool , Ramana Radhakrishnan , GCC Patches Subject: Re: [PATCH] rs6000 branch probability changes Message-ID: <20170701132351.GC20086@kam.mff.cuni.cz> References: <20170630231825.GN16550@gate.crashing.org> <20170701130625.GA6089@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2017-07/txt/msg00014.txt.bz2 > On Sat, Jul 1, 2017 at 9:06 AM, Jan Hubicka wrote: > >> >> > * config/rs6000/rs6000.c (emit_unlikely_jump): Adjust to new branch > >> >> > probability data type. > >> >> > > >> >> > Index: rs6000.c > >> >> > =================================================================== > >> >> > --- rs6000.c (revision 249839) > >> >> > +++ rs6000.c (working copy) > >> >> > @@ -23514,10 +23514,9 @@ > >> >> > static void > >> >> > emit_unlikely_jump (rtx cond, rtx label) > >> >> > { > >> >> > - int very_unlikely = REG_BR_PROB_BASE / 100 - 1; > >> >> > rtx x = gen_rtx_IF_THEN_ELSE (VOIDmode, cond, label, pc_rtx); > >> >> > rtx_insn *insn = emit_jump_insn (gen_rtx_SET (pc_rtx, x)); > >> >> > - add_int_reg_note (insn, REG_BR_PROB, very_unlikely); > >> >> > + add_int_reg_note (insn, REG_BR_PROB, profile_probability::very_unlikely ()); > >> >> > >> >> Hmmm isn't this very unlikely to work :) ? > >> >> > >> >> I used this as inspiration to do this for the arm ports but > >> >> add_int_reg_note expects an integer but very_unlikely returns > >> >> profile_probability ... > >> > > >> > It probably should be converted using to_reg_br_prob_base ? > >> > >> The comments in profile-count.h state that this should go away. > >> > >> We need advice from Honza about the preferred way to transform these idioms. > > > > I plan to change REG_BR_PROB notes to preserve all information from > > profile_probability (this is needed to make RTL expansion splitting work as > > expected), but for now they are still just REG_BR_PROB_BASE fixpoint. > > > > I think the code can stay as it is. I will add APIs for emitting/interpretting > > br_prob_nodes as followup (after debugging fixing issues with profile updating > > which I can now detect with the new type) > > > > Thanks for looking into this. > > Does the computed value of very_unlikely need to change for the new > scale? Can the profile machinery provide a helper function or macro > instead of the current calculation replicated in many ports? There is PROB_VERY_UNLIKELY macro which should be used in this context. Not sure how and whhen this very_unlikely got in. It is defined as (REG_BR_PROB_BASE / 2000 - 1) perhaps 2000 was consider just too strong here? Honza > > Thanks, David