From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2730 invoked by alias); 19 Jun 2017 11:11:36 -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 1632 invoked by uid 89); 19 Jun 2017 11:11:36 -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,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=predict, quality 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; Mon, 19 Jun 2017 11:11:34 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 41CB2547FCF; Mon, 19 Jun 2017 13:11:36 +0200 (CEST) Date: Mon, 19 Jun 2017 11:11:00 -0000 From: Jan Hubicka To: Martin =?iso-8859-2?Q?Li=B9ka?= Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH 2/3] Make early return predictor more precise. Message-ID: <20170619111135.GC72026@kam.mff.cuni.cz> References: <20170609140804.GI53583@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-06/txt/msg01292.txt.bz2 > Ok, you're right that we can preserve the predictor. However, let's consider following test-case: > > static > int baz(int a) > { > if (a == 1) > return 1; > > return 0; > } > > > static > int bar(int a) > { > if (a == 1) > return baz(a); > > return 0; > } > > static > int foo(int a) > { > if (a == 1) > return bar(a); > > return 12; > } > > int main(int argc, char **argv) > { > return foo(argc); > } > > There after einline we have: > > main (int argc, char * * argv) > { > int D.1832; > int _3; > int _4; > > [100.00%]: > if (argc_2(D) == 1) > goto ; [37.13%] > else > goto ; [62.87%] > > [37.13%]: > // predicted unlikely by early return (on trees) predictor. > // predicted unlikely by early return (on trees) predictor. > // predicted unlikely by early return (on trees) predictor. > > [100.00%]: > # _3 = PHI <12(2), 1(3)> > _5 = _3; > _4 = _5; > return _4; > > } > > I'm thinking what's the best place to merge all the predictor > statements? I wonder if we need to - predictors are relatively short lived. In fact they do not need to hit IPA passes but they do as at a time I was implementing them I was worrying about introducing yet another global IPA pass to remove them (we can't do during early inlining because we want to reuse them after inlining). I would just move pass_strip_predict_hints pre-IPA and not worry about them chaining. There is problem that after inlining the prediction may expand its scope and predict branch that it outside of the original function body, but I do not see very easy solution for that besides not re-doing prediction (we could also copy probabilities from the inlined function when they exists and honnor them in the outer function. I am not sure that is going to improve prediction quality though - extra context is probably useful) Thanks, Honza > > Thanks, > Martin > > > > > Where did you found this case? > > Honza > >> > >> /* Create a new deep copy of the statement. */ > >> copy = gimple_copy (stmt); > >> -- > >> 2.13.0 > >>