public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r14-8941] lower-bitint: Fix handle_cast when used e.g. in comparisons of precisions multiple of limb_prec [PR1 Date: Mon, 12 Feb 2024 19:46:32 +0000 (GMT) [thread overview] Message-ID: <20240212194632.E98173858C2C@sourceware.org> (raw) https://gcc.gnu.org/g:9511b91c56f08b319b4a407608f85c96029ce7ce commit r14-8941-g9511b91c56f08b319b4a407608f85c96029ce7ce Author: Jakub Jelinek <jakub@redhat.com> Date: Mon Feb 12 20:46:04 2024 +0100 lower-bitint: Fix handle_cast when used e.g. in comparisons of precisions multiple of limb_prec [PR113849] handle_cast handles the simple way all narrowing large/huge bitint to large/huge bitint conversions and also such widening conversions if we can assume that the most significant limb is processed using constant index and both lhs and rhs have same number of limbs. But, the condition whether we can rely on the most significant limb being processed using constant index is incorrect. For m_upwards_2limb it was correct (m_upwards_2limb then is the number of limbs handled by the loop, so if lhs_type has larger precision than that, it is handled with constant index), similarly if m_var_msb is set (on left shifts), it is never handled with constant idx. But in other cases, like right shifts or non-equality comparisons, or bitquery operations which operate from most significant to least significant limb, all those can handle even the most significant limb in a loop when lhs_type has precision which is a multiple of limb_prec. So, the following patch punts on the optimization in that case and goes for the conditionals in the loop for that case. 2024-02-12 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/113849 * gimple-lower-bitint.cc (bitint_large_huge::handle_cast): Don't use fast path for widening casts where !m_upwards_2limb and lhs_type has precision which is a multiple of limb_prec. * gcc.dg/torture/bitint-58.c: New test. Diff: --- gcc/gimple-lower-bitint.cc | 12 ++++++++---- gcc/testsuite/gcc.dg/torture/bitint-58.c | 25 +++++++++++++++++++++++++ 2 files changed, 33 insertions(+), 4 deletions(-) diff --git a/gcc/gimple-lower-bitint.cc b/gcc/gimple-lower-bitint.cc index caa33e0aacf1..0d132bf7b6c4 100644 --- a/gcc/gimple-lower-bitint.cc +++ b/gcc/gimple-lower-bitint.cc @@ -1267,13 +1267,17 @@ bitint_large_huge::handle_cast (tree lhs_type, tree rhs1, tree idx) the most significant limb is handled in straight line code. If m_var_msb (on left shifts) or if m_upwards_2limb * limb_prec is equal to - lhs precision that is not the case. */ + lhs precision or if not m_upwards_2limb and lhs_type + has precision which is multiple of limb_prec that is + not the case. */ || (!m_var_msb && (CEIL (TYPE_PRECISION (lhs_type), limb_prec) == CEIL (TYPE_PRECISION (rhs_type), limb_prec)) - && (!m_upwards_2limb - || (m_upwards_2limb * limb_prec - < TYPE_PRECISION (lhs_type))))) + && ((!m_upwards_2limb + && (TYPE_PRECISION (lhs_type) % limb_prec != 0)) + || (m_upwards_2limb + && (m_upwards_2limb * limb_prec + < TYPE_PRECISION (lhs_type)))))) { rhs1 = handle_operand (rhs1, idx); if (tree_fits_uhwi_p (idx)) diff --git a/gcc/testsuite/gcc.dg/torture/bitint-58.c b/gcc/testsuite/gcc.dg/torture/bitint-58.c new file mode 100644 index 000000000000..bdadd8b88d67 --- /dev/null +++ b/gcc/testsuite/gcc.dg/torture/bitint-58.c @@ -0,0 +1,25 @@ +/* PR tree-optimization/113849 */ +/* { dg-do run { target bitint } } */ +/* { dg-options "-std=c23 -pedantic-errors" } */ +/* { dg-skip-if "" { ! run_expensive_tests } { "*" } { "-O0" "-O2" } } */ +/* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */ + +signed char c; +unsigned _BitInt(512) b; + +__attribute__((noipa)) void +foo (unsigned _BitInt(511) a, int *x) +{ + int z = (a << 510) <= b; + *x = z + c; +} + +int +main () +{ + int x; + foo (2, &x); + if (x != 1) + __builtin_abort (); + return 0; +}
reply other threads:[~2024-02-12 19:46 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=20240212194632.E98173858C2C@sourceware.org \ --to=jakub@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).