public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Patrick Palka <ppalka@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r10-11124] c++: quadratic constexpr behavior for left-assoc logical exprs [PR102780] Date: Fri, 16 Dec 2022 21:14:35 +0000 (GMT) [thread overview] Message-ID: <20221216211435.EC0FA3851883@sourceware.org> (raw) https://gcc.gnu.org/g:16605ad9b1e1a6c5aab2c98b5b0f995285584f81 commit r10-11124-g16605ad9b1e1a6c5aab2c98b5b0f995285584f81 Author: Patrick Palka <ppalka@redhat.com> Date: Thu Oct 28 10:05:14 2021 -0400 c++: quadratic constexpr behavior for left-assoc logical exprs [PR102780] In the testcase below the two left fold expressions each expand into a constant logical expression with 1024 terms, for which potential_const_expr takes more than a minute to return true. This happens because p_c_e_1 performs trial evaluation of the first operand of a &&/|| in order to determine whether to consider the potentiality of the second operand. And because the expanded expression is left-associated, this trial evaluation causes p_c_e_1 to be quadratic in the number of terms of the expression. This patch fixes this quadratic behavior by making p_c_e_1 preemptively compute potentiality of the second operand of a &&/||, and perform trial evaluation of the first operand only if the second operand isn't potentially constant. We must be careful to avoid emitting bogus diagnostics during the preemptive computation; to that end, we perform this shortcut only when tf_error is cleared, and when tf_error is set we now first check potentiality of the whole expression quietly and replay the check noisily for diagnostics. Apart from fixing the quadraticness for left-associated logical exprs, this change also reduces compile time for the libstdc++ testcase 20_util/variant/87619.cc by about 15% even though our <variant> uses right folds instead of left folds. Likewise for the testcase in the PR, for which compile time is reduced by 30%. The reason for these speedups is that p_c_e_1 no longer performs expensive trial evaluation of each term of large constant logical expressions when determining their potentiality. PR c++/102780 PR c++/108138 gcc/cp/ChangeLog: * constexpr.c (potential_constant_expression_1) <case TRUTH_*_EXPR>: When tf_error isn't set, preemptively check potentiality of the second operand before performing trial evaluation of the first operand. (potential_constant_expression_1): When tf_error is set, first check potentiality quietly and return true if successful, otherwise proceed noisily to give errors. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/fold13.C: New test. (cherry picked from commit 9927ecbb42d5be48fa933adc26f8601fab5007ca) Diff: --- gcc/cp/constexpr.c | 26 +++++++++++++++++++++----- gcc/testsuite/g++.dg/cpp1z/fold13.C | 29 +++++++++++++++++++++++++++++ 2 files changed, 50 insertions(+), 5 deletions(-) diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c index 40066a3330f..369920eda90 100644 --- a/gcc/cp/constexpr.c +++ b/gcc/cp/constexpr.c @@ -8425,13 +8425,18 @@ potential_constant_expression_1 (tree t, bool want_rval, bool strict, bool now, tmp = boolean_false_node; truth: { - tree op = TREE_OPERAND (t, 0); - if (!RECUR (op, rval)) + tree op0 = TREE_OPERAND (t, 0); + tree op1 = TREE_OPERAND (t, 1); + if (!RECUR (op0, rval)) return false; + if (!(flags & tf_error) && RECUR (op1, rval)) + /* When quiet, try to avoid expensive trial evaluation by first + checking potentiality of the second operand. */ + return true; if (!processing_template_decl) - op = cxx_eval_outermost_constant_expr (op, true); - if (tree_int_cst_equal (op, tmp)) - return RECUR (TREE_OPERAND (t, 1), rval); + op0 = cxx_eval_outermost_constant_expr (op0, true); + if (tree_int_cst_equal (op0, tmp)) + return (flags & tf_error) ? RECUR (op1, rval) : false; else return true; } @@ -8611,6 +8616,17 @@ bool potential_constant_expression_1 (tree t, bool want_rval, bool strict, bool now, tsubst_flags_t flags) { + if (flags & tf_error) + { + /* Check potentiality quietly first, as that could be performed more + efficiently in some cases (currently only for TRUTH_*_EXPR). If + that fails, replay the check noisily to give errors. */ + flags &= ~tf_error; + if (potential_constant_expression_1 (t, want_rval, strict, now, flags)) + return true; + flags |= tf_error; + } + tree target = NULL_TREE; return potential_constant_expression_1 (t, want_rval, strict, now, flags, &target); diff --git a/gcc/testsuite/g++.dg/cpp1z/fold13.C b/gcc/testsuite/g++.dg/cpp1z/fold13.C new file mode 100644 index 00000000000..9d7554f8999 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp1z/fold13.C @@ -0,0 +1,29 @@ +// { dg-do compile { target c++17 } } +// Verify constexpr evaluation of a large left fold logical expression +// isn't quadratic in the size of the expanded expression. + +template<int> struct S { static constexpr bool value = true; }; + +template<class T, T...> struct integer_sequence { }; + +template<class T, T N> +using make_integer_sequence +#if __has_builtin(__make_integer_seq) + = __make_integer_seq<integer_sequence, T, N>; +#else + = integer_sequence<T, __integer_pack(N)...>; +#endif + +template<int... Is> +constexpr bool f_impl(integer_sequence<int, Is...>) { + return (... && S<Is>::value); +} + +static_assert(f_impl(make_integer_sequence<int, 1024>())); + +template<int... Is> +constexpr bool g_impl(integer_sequence<int, Is...>) { + return (... || !S<Is>::value); +} + +static_assert(!g_impl(make_integer_sequence<int, 1024>()));
reply other threads:[~2022-12-16 21:14 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20221216211435.EC0FA3851883@sourceware.org \ --to=ppalka@gcc.gnu.org \ --cc=gcc-cvs@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: linkBe 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).