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
next prev parent 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).