public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/38074] [4.4 Regression] missed inlining on Core2 Duo due to apparent wrong branch prediction/profile Date: Fri, 05 Dec 2008 17:17:00 -0000 [thread overview] Message-ID: <20081205171548.30032.qmail@sourceware.org> (raw) In-Reply-To: <bug-38074-12313@http.gcc.gnu.org/bugzilla/> ------- Comment #11 from hubicka at ucw dot cz 2008-12-05 17:15 ------- Subject: Re: [4.4 Regression] missed inlining on Core2 Duo due to apparent wrong branch prediction/profile OK, so the problem is that all the paths are leading to noreturn, so the conditional deciding on what noreturn path will be taken is predictor by same heuristic in both dirrections. Our first math heuristic blindly picks the first one in row predicting the "invalid command line parameters" path to be very likely and main body to be very unlikely. This patch fixes it in both ways: when all paths are leading to noreturn, we disable the heuristics and when heuristics is taken into consideration for first match we first check that it was not confused and did not predict edge in both ways. I also fixed nonsence in compute_call_stmt_bb_frequency noticed by Jakub. To make frequencies at least little bit sane, I simply add 1 to both values so we still get calls with higher frequency than 0 predicted as more often. Honza Jan Hubicka <jh@suse.cz> Jakub Jelinek <jakub@redhat.com> * cgraphbuild.c (compute_call_stmt_bb_frequency): Fix handling of 0 entry frequency. * predict.c (combine_predictions_for_bb): Ignore predictor predicting in both dirrection for first match heuristics. (tree_bb_level_predictions): Disable noreturn heuristic when there is no returning path. Index: cgraphbuild.c =================================================================== *** cgraphbuild.c (revision 141929) --- cgraphbuild.c (working copy) *************** int *** 109,121 **** compute_call_stmt_bb_frequency (basic_block bb) { int entry_freq = ENTRY_BLOCK_PTR->frequency; ! int freq; if (!entry_freq) ! entry_freq = 1; ! freq = (!bb->frequency && !entry_freq ? CGRAPH_FREQ_BASE ! : bb->frequency * CGRAPH_FREQ_BASE / entry_freq); if (freq > CGRAPH_FREQ_MAX) freq = CGRAPH_FREQ_MAX; --- 109,120 ---- compute_call_stmt_bb_frequency (basic_block bb) { int entry_freq = ENTRY_BLOCK_PTR->frequency; ! int freq = bb->frequency; if (!entry_freq) ! entry_freq = 1, freq++; ! freq = freq * CGRAPH_FREQ_BASE / entry_freq; if (freq > CGRAPH_FREQ_MAX) freq = CGRAPH_FREQ_MAX; Index: predict.c =================================================================== *** predict.c (revision 141929) --- predict.c (working copy) *************** combine_predictions_for_bb (basic_block *** 820,827 **** probability = REG_BR_PROB_BASE - probability; found = true; if (best_predictor > predictor) ! best_probability = probability, best_predictor = predictor; d = (combined_probability * probability + (REG_BR_PROB_BASE - combined_probability) --- 820,852 ---- probability = REG_BR_PROB_BASE - probability; found = true; + /* First match heuristics would be widly confused if we predicted + both directions. */ if (best_predictor > predictor) ! { ! struct edge_prediction *pred2; ! int prob = probability; ! ! for (pred2 = (struct edge_prediction *) *preds; pred2; pred2 = pred2->ep_next) ! if (pred2 != pred && pred2->ep_predictor == pred->ep_predictor) ! { ! int probability2 = pred->ep_probability; ! ! if (pred2->ep_edge != first) ! probability2 = REG_BR_PROB_BASE - probability2; ! ! if ((probability < REG_BR_PROB_BASE / 2) != ! (probability2 < REG_BR_PROB_BASE / 2)) ! break; ! ! /* If the same predictor later gave better result, go for it! */ ! if ((probability >= REG_BR_PROB_BASE / 2 && (probability2 > probability)) ! || (probability <= REG_BR_PROB_BASE / 2 && (probability2 < probability))) ! prob = probability2; ! } ! if (!pred2) ! best_probability = prob, best_predictor = predictor; ! } d = (combined_probability * probability + (REG_BR_PROB_BASE - combined_probability) *************** static void *** 1521,1526 **** --- 1546,1561 ---- tree_bb_level_predictions (void) { basic_block bb; + bool has_return_edges = false; + edge e; + edge_iterator ei; + + FOR_EACH_EDGE (e, ei, EXIT_BLOCK_PTR->preds) + if (!(e->flags & (EDGE_ABNORMAL | EDGE_FAKE | EDGE_EH))) + { + has_return_edges = true; + break; + } apply_return_prediction (); *************** tree_bb_level_predictions (void) *** 1535,1541 **** if (is_gimple_call (stmt)) { ! if (gimple_call_flags (stmt) & ECF_NORETURN) predict_paths_leading_to (bb, PRED_NORETURN, NOT_TAKEN); decl = gimple_call_fndecl (stmt); --- 1570,1577 ---- if (is_gimple_call (stmt)) { ! if ((gimple_call_flags (stmt) & ECF_NORETURN) ! && has_return_edges) predict_paths_leading_to (bb, PRED_NORETURN, NOT_TAKEN); decl = gimple_call_fndecl (stmt); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38074
next prev parent reply other threads:[~2008-12-05 17:17 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-11-10 20:30 [Bug middle-end/38074] New: [4.4 Regression] missed inlining since IRA merge on Core2 Duo dominiq at lps dot ens dot fr 2008-11-11 20:22 ` [Bug middle-end/38074] " rguenth at gcc dot gnu dot org 2008-11-11 20:39 ` dominiq at lps dot ens dot fr 2008-11-11 21:20 ` jakub at gcc dot gnu dot org 2008-11-25 16:35 ` rguenth at gcc dot gnu dot org 2008-11-28 11:08 ` jakub at gcc dot gnu dot org 2008-11-28 11:21 ` rguenth at gcc dot gnu dot org 2008-11-28 11:47 ` jakub at gcc dot gnu dot org 2008-11-28 12:57 ` jakub at gcc dot gnu dot org 2008-12-05 12:46 ` [Bug middle-end/38074] [4.4 Regression] missed inlining on Core2 Duo due to apparent wrong branch prediction/profile rguenth at gcc dot gnu dot org 2008-12-05 13:00 ` hubicka at ucw dot cz 2008-12-05 17:09 ` hubicka at gcc dot gnu dot org 2008-12-05 17:17 ` hubicka at ucw dot cz [this message] 2008-12-06 8:37 ` hubicka at gcc dot gnu dot org 2008-12-06 9:05 ` jakub at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20081205171548.30032.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).