public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@adacore.com>
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] [PR105455] predict: Check for no REG_BR_PROB in uninitialized case
Date: Wed, 11 May 2022 22:48:50 -0300	[thread overview]
Message-ID: <orilqbikql.fsf@lxoliva.fsfla.org> (raw)


There is an assumption in force_edge_cold that, if any edge out of the
same src block has uninitialized probability, then a conditional
branch out of src won't have REG_BR_PROB set.

This assumption is supposed to hold, but buggy gimple passes may turn
unconditional edges into conditional ones, adding edges with
uninitialized probability out of blocks that retain originally
unconditional edges with precise always probability.  Expand may then
copy the formerly-unconditional edge's probability to REG_BR_PROB, and
if that edge ends up forced cold, the probability in the edge will be
modified without adjusting the note, and rtl_verify_edges complains
about that.

This patch adds checking that REG_BR_PROB is absent to the path taken
by force_cold_edge for uninitialized probabilities, so that the
problem is caught earlier and fixed sooner.

I'm not sure it buys us much, but...  Regstrapped on x86_64-linux-gnu.
Ok to install?


for  gcc/ChangeLog

	* predict.cc (force_edge_cold): Check for no REG_BR_PROB in
	the uninitialized probability case.
---
 gcc/predict.cc |   14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/gcc/predict.cc b/gcc/predict.cc
index 5734e4c851630..48ac81624ec4a 100644
--- a/gcc/predict.cc
+++ b/gcc/predict.cc
@@ -4378,7 +4378,19 @@ force_edge_cold (edge e, bool impossible)
   /* If we are not guessing profiles but have some other edges out,
      just assume the control flow goes elsewhere.  */
   if (uninitialized_exit)
-    e->probability = goal;
+    {
+      e->probability = goal;
+#if CHECKING_P
+      /* We don't expect to have a REG_BR_PROB note to adjust when
+	 there were edges with uninitialized probabilities.  This
+	 would be a symptom of creating edges, before expand, without
+	 assigning probabilities, while other edges have them. */
+      if (current_ir_type () != IR_GIMPLE
+	  && e->src != ENTRY_BLOCK_PTR_FOR_FN (cfun))
+	gcc_checking_assert (!find_reg_note (BB_END (e->src),
+					     REG_BR_PROB, NULL_RTX));
+#endif
+    }
   /* If there are other edges out of e->src, redistribute probabilitity
      there.  */
   else if (prob_sum > profile_probability::never ())

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

             reply	other threads:[~2022-05-12  1:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-12  1:48 Alexandre Oliva [this message]
2022-06-26 18:49 ` Jeff Law

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=orilqbikql.fsf@lxoliva.fsfla.org \
    --to=oliva@adacore.com \
    --cc=gcc-patches@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: link
Be 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).