public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Marek Polacek <polacek@redhat.com>
To: Jason Merrill <jason@redhat.com>
Cc: Patrick Palka <ppalka@redhat.com>, GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH v3] c++: Fix compile-time-hog in cp_fold_immediate_r [PR111660]
Date: Thu, 19 Oct 2023 14:45:43 -0400	[thread overview]
Message-ID: <ZTF5VyDZQVKn2nQg@redhat.com> (raw)
In-Reply-To: <3f79ba91-6d2c-425e-a9a2-ff353c8d71a7@redhat.com>

On Thu, Oct 19, 2023 at 01:02:33PM -0400, Jason Merrill wrote:
> On 10/19/23 12:55, Marek Polacek wrote:
> > On Thu, Oct 19, 2023 at 12:32:49PM -0400, Jason Merrill wrote:
> > > On 10/19/23 10:14, Marek Polacek wrote:
> > > > On Thu, Oct 19, 2023 at 10:06:01AM -0400, Jason Merrill wrote:
> > > > > On 10/19/23 09:39, Patrick Palka wrote:
> > > > > > On Tue, 17 Oct 2023, Marek Polacek wrote:
[...]
> > > > > > > > >          case PTRMEM_CST:
> > > > > > > > >            if (TREE_CODE (PTRMEM_CST_MEMBER (stmt)) == FUNCTION_DECL
> > > > > > > > >      	  && DECL_IMMEDIATE_FUNCTION_P (PTRMEM_CST_MEMBER (stmt)))
> > > > > > > > > @@ -1162,8 +1141,35 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void *data_)
> > > > > > > > >        tree stmt = *stmt_p;
> > > > > > > > >        enum tree_code code = TREE_CODE (stmt);
> > > > > > > > > -  if (cxx_dialect > cxx17)
> > > > > > > > > -    cp_fold_immediate_r (stmt_p, walk_subtrees, data);
> > > > > > > > > +  if (cxx_dialect >= cxx20)
> > > > > > > > > +    {
> > > > > > > > > +      /* Unfortunately we must handle code like
> > > > > > > > > +	   false ? bar () : 42
> > > > > > > > > +	 where we have to check bar too.  The cp_fold call below could
> > > > > > > > > +	 fold the ?: into a constant before we've checked it.  */
> > > > > > > > > +      if (code == COND_EXPR)
> > > > > > > > > +	{
> > > > > > > > > +	  auto then_fn = cp_fold_r, else_fn = cp_fold_r;
> > > > > > > > > +	  /* See if we can figure out if either of the branches is dead.  If it
> > > > > > > > > +	     is, we don't need to do everything that cp_fold_r does.  */
> > > > > > > > > +	  tree cond = maybe_constant_value (TREE_OPERAND (stmt, 0));
> > > > > > > > > +	  if (integer_zerop (cond))
> > > > > > > > > +	    then_fn = cp_fold_immediate_r;
> > > > > > > > > +	  else if (TREE_CODE (cond) == INTEGER_CST)
> > > > > > > > > +	    else_fn = cp_fold_immediate_r;
> > > > > > > > > +
> > > > > > > > > +	  cp_walk_tree (&TREE_OPERAND (stmt, 0), cp_fold_r, data, nullptr);
> > > > > > > > 
> > > > > > > > I wonder about doing this before maybe_constant_value, to hopefully reduce
> > > > > > > > the redundant calculations?  OK either way.
> > > > > > > 
> > > > > > > Yeah, I was toying with that, I had
> > > > > > > 
> > > > > > >      foo() ? x : y
> > > > > > > 
> > > > > > > where foo was a constexpr function but the cp_fold_r on op0 didn't eval it
> > > > > > > to a constant :(.
> > > > > > 
> > > > > > IIUC that's because cp_fold evaluates constexpr calls only with -O, so
> > > > > > doing cp_fold_r before maybe_constant_value on the condition should
> > > > > > still be desirable in that case?
> > > > > 
> > > > > Hmm, and if the cp_fold_r doesn't reduce the test to a constant, I would
> > > > > think that folding the COND_EXPR also won't discard the other branch, so we
> > > > > shouldn't need to work harder to get a constant here, so we don't need to
> > > > > call maybe_constant_value at all?
> > > > 
> > > > Sorry, I hadn't seen this message when I posted the tweak.  But the
> > > > maybe_constant_value call on TREE_OPERAND (stmt, 0) should still make
> > > > sense because it can render a branch dead even on -O0.  Right?
> > > 
> > > But if op0 isn't constant after cp_fold, folding the COND_EXPR won't discard
> > > the branch, so we don't need to do the extra work to find out that it's
> > > actually dead.
> > 
> > Hmm, so how about this?  Thus far dg.exp passed.
> > 
> > -- >8 --
> > This patch is an optimization tweak for cp_fold_r.  If we cp_fold_r the
> > COND_EXPR's op0 first, we may be able to evaluate it to a constant if -O.
> > cp_fold has:
> > 
> > 3143         if (callee && DECL_DECLARED_CONSTEXPR_P (callee)
> > 3144             && !flag_no_inline)
> > ...
> > 3151             r = maybe_constant_value (x, /*decl=*/NULL_TREE,
> > 
> > flag_no_inline is 1 for -O0:
> > 
> > 1124   if (opts->x_optimize == 0)
> > 1125     {
> > 1126       /* Inlining does not work if not optimizing,
> > 1127          so force it not to be done.  */
> > 1128       opts->x_warn_inline = 0;
> > 1129       opts->x_flag_no_inline = 1;
> > 1130     }
> > 
> > but otherwise it's 0 and cp_fold will maybe_constant_value calls to
> > constexpr functions.  And if it doesn't, then folding the COND_EXPR
> > will keep both arms, and we can avoid calling maybe_constant_value.
> > 
> > gcc/cp/ChangeLog:
> > 
> > 	* cp-gimplify.cc (cp_fold_r): Don't call maybe_constant_value.
> > ---
> >   gcc/cp/cp-gimplify.cc | 7 +++----
> >   1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
> > index a282c3930a3..385042aeef2 100644
> > --- a/gcc/cp/cp-gimplify.cc
> > +++ b/gcc/cp/cp-gimplify.cc
> > @@ -1152,13 +1152,12 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void *data_)
> >   	  auto then_fn = cp_fold_r, else_fn = cp_fold_r;
> >   	  /* See if we can figure out if either of the branches is dead.  If it
> >   	     is, we don't need to do everything that cp_fold_r does.  */
> > -	  tree cond = maybe_constant_value (TREE_OPERAND (stmt, 0));
> > -	  if (integer_zerop (cond))
> > +	  cp_walk_tree (&TREE_OPERAND (stmt, 0), cp_fold_r, data, nullptr);
> > +	  if (integer_zerop (TREE_OPERAND (stmt, 0)))
> >   	    then_fn = cp_fold_immediate_r;
> > -	  else if (TREE_CODE (cond) == INTEGER_CST)
> > +	  else if (TREE_CODE (TREE_OPERAND (stmt, 0)) == INTEGER_CST)
> 
> You probably want to STRIP_NOPS before checking the TREE_CODE, like
> fold_ternary_loc and integer_zerop do.

Ok, or use integer_nonzerop like Patrick suggested:

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --
This patch is an optimization tweak for cp_fold_r.  If we cp_fold_r the
COND_EXPR's op0 first, we may be able to evaluate it to a constant if -O.
cp_fold has:

3143         if (callee && DECL_DECLARED_CONSTEXPR_P (callee)
3144             && !flag_no_inline)
...
3151             r = maybe_constant_value (x, /*decl=*/NULL_TREE,

flag_no_inline is 1 for -O0:

1124   if (opts->x_optimize == 0)
1125     {
1126       /* Inlining does not work if not optimizing,
1127          so force it not to be done.  */
1128       opts->x_warn_inline = 0;
1129       opts->x_flag_no_inline = 1;
1130     }

but otherwise it's 0 and cp_fold will maybe_constant_value calls to
constexpr functions.  And if it doesn't, then folding the COND_EXPR
will keep both arms, and we can avoid calling maybe_constant_value.

gcc/cp/ChangeLog:

	* cp-gimplify.cc (cp_fold_r): Don't call maybe_constant_value.
---
 gcc/cp/cp-gimplify.cc | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
index a282c3930a3..33e9411f10c 100644
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -1152,13 +1152,12 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void *data_)
 	  auto then_fn = cp_fold_r, else_fn = cp_fold_r;
 	  /* See if we can figure out if either of the branches is dead.  If it
 	     is, we don't need to do everything that cp_fold_r does.  */
-	  tree cond = maybe_constant_value (TREE_OPERAND (stmt, 0));
-	  if (integer_zerop (cond))
+	  cp_walk_tree (&TREE_OPERAND (stmt, 0), cp_fold_r, data, nullptr);
+	  if (integer_zerop (TREE_OPERAND (stmt, 0)))
 	    then_fn = cp_fold_immediate_r;
-	  else if (TREE_CODE (cond) == INTEGER_CST)
+	  else if (integer_nonzerop (TREE_OPERAND (stmt, 0)))
 	    else_fn = cp_fold_immediate_r;
 
-	  cp_walk_tree (&TREE_OPERAND (stmt, 0), cp_fold_r, data, nullptr);
 	  if (TREE_OPERAND (stmt, 1))
 	    cp_walk_tree (&TREE_OPERAND (stmt, 1), then_fn, data,
 			  nullptr);

base-commit: d8e4e7def3338344a761d841010e98d017c58b0a
-- 
2.41.0


  reply	other threads:[~2023-10-19 18:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-12 21:04 [PATCH] " Marek Polacek
2023-10-13  1:41 ` Jason Merrill
2023-10-13 18:53   ` [PATCH v2] " Marek Polacek
2023-10-14  5:13     ` Jason Merrill
2023-10-17  0:39       ` [PATCH v3] " Marek Polacek
2023-10-17 20:49         ` Jason Merrill
2023-10-17 20:54           ` Marek Polacek
2023-10-19 13:39             ` Patrick Palka
2023-10-19 14:06               ` Jason Merrill
2023-10-19 14:14                 ` Marek Polacek
2023-10-19 16:32                   ` Jason Merrill
2023-10-19 16:55                     ` Marek Polacek
2023-10-19 17:02                       ` Jason Merrill
2023-10-19 18:45                         ` Marek Polacek [this message]
2023-10-19 20:11                           ` Jason Merrill
2023-10-19 14:09               ` Marek Polacek

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=ZTF5VyDZQVKn2nQg@redhat.com \
    --to=polacek@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=ppalka@redhat.com \
    /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).