On Thu, Oct 19, 2023 at 09:39:27AM -0400, Patrick Palka wrote:
> On Tue, 17 Oct 2023, Marek Polacek wrote:
> 
> > On Tue, Oct 17, 2023 at 04:49:52PM -0400, Jason Merrill wrote:
> > > On 10/16/23 20:39, Marek Polacek wrote:
> > > > -  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?

Ah yeah, it depends on whether -fno-inline is on or off as described below.

OK if testing passes?  Thanks,

-- >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,
saving some work.  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.

gcc/cp/ChangeLog:

        * cp-gimplify.cc (cp_fold_r): cp_fold_r the first operand of a COND_EXPR
        before calling maybe_constant_value.
---
 gcc/cp/cp-gimplify.cc | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
index a282c3930a3..746de86dfa6 100644
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -1151,14 +1151,16 @@ 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.  */
+            is, we don't need to do everything that cp_fold_r does.  If we
+            cp_fold_r first, there's a chance it will evaluate the condition to
+            a constant so maybe_constant_value won't have a lot of work to do. 
 */
+         cp_walk_tree (&TREE_OPERAND (stmt, 0), cp_fold_r, data, nullptr);
          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);
          if (TREE_OPERAND (stmt, 1))
            cp_walk_tree (&TREE_OPERAND (stmt, 1), then_fn, data,
                          nullptr);

base-commit: 19cc4b9d74940f29c961e2a5a8b1fa84992d3d30
-- 
2.41.0

Reply via email to