public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/104196] [12 Regression] wrong code at -O2 and above on x86_64-linux-gnu
Date: Thu, 27 Jan 2022 09:47:55 +0000	[thread overview]
Message-ID: <bug-104196-4-mAJY0v3IxD@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-104196-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104196

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:82c8ff79d06cc7d389c72f94d4443c509cf85313

commit r12-6888-g82c8ff79d06cc7d389c72f94d4443c509cf85313
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Jan 27 10:47:00 2022 +0100

    reassoc: Fix up inter-bb range optimization [PR104196]

    As mentioned in the PR, reassoc1 miscompiles following testcase.
    We have:
      if (a.1_1 >= 0)
        goto <bb 5>; [59.00%]
      else
        goto <bb 4>; [41.00%]

      <bb 4> [local count: 440234144]:
      _3 = -2147483647 - a.1_1;
      _9 = a.1_1 != -2147479551;
      _4 = _3 == 1;
      _8 = _4 | _9;
      if (_8 != 0)
        goto <bb 5>; [34.51%]
      else
        goto <bb 3>; [65.49%]

    and the inter-bb range test optimization treats it as:
      if ((a.1_1 >= 0)
          | (-2147483647 - a.1_1 == 1)
          | (a.1_1 != -2147479551))
        goto bb5;
      else
        goto bb3;
    and recognizes that a.1_1 >= 0 is redundant with a.1_1 != -2147479551
    and so will optimize it into:
      if (0
          | (-2147483647 - a.1_1 == 1)
          | (a.1_1 != -2147479551))
        goto bb5;
      else
        goto bb3;
    When merging 2 comparisons, we use update_range_test which picks one
    of the comparisons as the one holding the result (currently always
    the RANGE one rather than all the OTHERRANGE* ones) and adjusts the
    others to be true or false.
    The problem with doing that is that means the
      _3 = -2147483647 - a.1_1;
    stmt with undefined behavior on overflow used to be conditional before
    but now is unconditional.  reassoc performs a no_side_effect_bb check
    which among other checks punts on gimple_has_side_effects and
    gimple_assign_rhs_could_trap_p stmts as well as ones that have uses of
    their lhs outside of the same bb, but it doesn't punt for this potential
    signed overflow case.

    Now, for this testcase, it can be fixed in update_range_test by being
    smarter and choosing the other comparison to modify.  This is achieved
    by storing into oe->id index of the bb with GIMPLE_COND the
    comparison feeds into not just for the cases where the comparison is
    the GIMPLE_COND itself, but in all cases, and then finding oe->id that
    isn't dominated by others.  If we find such, use that oe for the merge
    test and if successful, swap range->idx and swap_with->idx.
    So for the above case we optimize it into:
      if ((a.1_1 != -2147479551)
          | (-2147483647 - a.1_1 == 1)
          | 0)
        goto bb5;
      else
        goto bb3;
    instead.

    Unfortunately, this doesn't work in all cases,
    optimize_range_tests_to_bit_test and
    optimize_range_tests_cmp_bitwise optimizations use non-NULL seq
    to update_range_test and they carefully choose a particular comparison
    because the sequence then uses SSA_NAMEs that may be defined only in
    their blocks.  For that case, the patch keeps using the chosen comparison
    but if the merge is successful, rewrites stmts with signed overflow
behavior
    into defined overflow.
    For this I ran into a problem, rewrite_to_defined_overflow returns a
    sequence that includes the original stmt with modified arguments, this
means
    it needs to be gsi_remove first.  Unfortunately, gsi_remove regardless of
    the remove_permanently argument creates debug temps for the lhs, which I
    think is quite undesirable here.  So I've added an argument (default to
    false) to rewrite_to_defined_overflow to do the modification in place
    without the need to remove the stmt.

    2022-01-27  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/104196
            * gimple-fold.h (rewrite_to_defined_overflow): Add IN_PLACE
argument.
            * gimple-fold.cc (rewrite_to_defined_overflow): Likewise.  If true,
            return NULL and emit needed stmts before and after stmt.
            * tree-ssa-reassoc.cc (update_range_test): For inter-bb range opt
            pick as operand_entry that will hold the merged test the one
feeding
            earliest condition, ensure that by swapping range->idx with some
            other range's idx if needed.  If seq is non-NULL, don't actually
swap
            it but instead rewrite stmts with undefined overflow in between
            the two locations.
            (maybe_optimize_range_tests): Set ops[]->id to bb->index with the
            corresponding condition even if they have non-NULL ops[]->op.
            Formatting fix.

            * gcc.c-torture/execute/pr104196.c: New test.

  parent reply	other threads:[~2022-01-27  9:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-24  0:01 [Bug c/104196] New: " cnsun at uwaterloo dot ca
2022-01-24  0:17 ` [Bug middle-end/104196] " jakub at gcc dot gnu.org
2022-01-24  0:17 ` [Bug tree-optimization/104196] [12 Regression] " jakub at gcc dot gnu.org
2022-01-24  0:37 ` pinskia at gcc dot gnu.org
2022-01-24  1:52 ` pinskia at gcc dot gnu.org
2022-01-24  2:00 ` pinskia at gcc dot gnu.org
2022-01-24  2:17 ` pinskia at gcc dot gnu.org
2022-01-24  2:19 ` pinskia at gcc dot gnu.org
2022-01-24  5:58 ` belyshev at depni dot sinp.msu.ru
2022-01-24 16:12 ` jakub at gcc dot gnu.org
2022-01-26 10:52 ` jakub at gcc dot gnu.org
2022-01-26 14:07 ` jakub at gcc dot gnu.org
2022-01-27  9:47 ` cvs-commit at gcc dot gnu.org [this message]
2022-01-27 10:20 ` jakub at gcc dot gnu.org

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=bug-104196-4-mAJY0v3IxD@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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: 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).