sume m_c_e is false. We can't re-use ff_genericize here because that
flag has additional effects in cp_fold_r, so it seems we need another
flag that that only affects the manifestly constant-eval stuff; I called
it ff_mce_false. How does the following look?
-- >8 --
Subject: [PATCH 2/2] c+
gt; > > > > > > > @@ -2944,7 +2954,15 @@ cp_fold (tree x)
> > > > > > > >constant, but the call followed by an INDIRECT_REF
> > > > > > > > is. */
> > > > > > > > if (callee &a
; ff_genericize)
> > > > > > > + /* At genericization time it's safe to fold
> > > > > > > + __builtin_is_constant_evaluated to false. */
> > > > > > > + manifestly_const_eval = mce_false;
> > > > > &
}
> > > > > > optimize = sv;
> > > > > > if (TREE_CODE (r) != CALL_EXPR)
> > > > > > @@ -2971,7 +2989,7 @@ cp_fold (tree x)
> > > > > > vec *nelts = NULL;
> > > > > &
d when called from the latter entry point to also
assume m_c_e is false. We can't re-use ff_genericize here because that
flag has additional effects in cp_fold_r, so it seems we need another
flag that that only affects the manifestly constant-eval stuff; I called
it ff_mce_false. How does
(x);
> > > > - op0 = cp_fold (TREE_OPERAND (x, 0));
> > > > - op1 = cp_fold (TREE_OPERAND (x, 1));
> > > > - op2 = cp_fold (TREE_OPERAND (x, 2));
> > > > - op3 = cp_fold (TREE_OPERAND (x, 3));
> > > > + op0
evealed that cp_fold_function doesn't reach static
initializers; that's taken care of by cp_fully_fold_init. So it seems
we need to make cp_fold when called from the latter entry point to also
assume m_c_e is false. We can't re-use ff_genericize here because that
flag has additional effect
this folded tree with a SAVE_EXPR. */
> > > - r = cp_fold (TREE_OPERAND (x, 0));
> > > + r = cp_fold (TREE_OPERAND (x, 0), flags);
> > > if (tree_invariant_p (r))
> > > x = r;
> > > break;
> > > @@ -
> copy_warning (x, org_x);
> > }
> > - if (!c.evaluation_restricted_p ())
> > + if (cache_p && !c.evaluation_restricted_p ())
> > {
> > fold_cache->put (org_x, x);
> > /* Prevent that we try to fold an already fo
On 1/27/23 17:02, Patrick Palka wrote:
This PR illustrates that __builtin_is_constant_evaluated currently acts
as an optimization barrier for our speculative constexpr evaluation,
since we don't want to prematurely fold the builtin to false if the
expression in question would be later manifestly
On Fri, 27 Jan 2023, Patrick Palka wrote:
> This PR illustrates that __builtin_is_constant_evaluated currently acts
> as an optimization barrier for our speculative constexpr evaluation,
> since we don't want to prematurely fold the builtin to false if the
> expression in question would be later m
This PR illustrates that __builtin_is_constant_evaluated currently acts
as an optimization barrier for our speculative constexpr evaluation,
since we don't want to prematurely fold the builtin to false if the
expression in question would be later manifestly constant evaluated (in
which case it must
12 matches
Mail list logo
