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 rtl-optimization/111702] [14 Regression] ICE: in insert_regs, at cse.cc:1114 with -O2 -fstack-protector-all -frounding-math
Date: Wed, 20 Dec 2023 19:07:46 +0000	[thread overview]
Message-ID: <bug-111702-4-02jOYIM1NH@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-111702-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:08ab2293dcce442e139b163ba22f65a32e7ebd6c

commit r14-6757-g08ab2293dcce442e139b163ba22f65a32e7ebd6c
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Wed Dec 20 19:07:35 2023 +0000

    cse: Fix handling of fake vec_select sets [PR111702]

    If cse sees:

      (set (reg R) (const_vector [A B ...]))

    it creates fake sets of the form:

      (set R[0] A)
      (set R[1] B)
      ...

    (with R[n] replaced by appropriate rtl) and then adds them to the tables
    in the same way as for normal sets.  This allows a sequence like:

      (set (reg R2) A)
      ...(reg R2)...

    to try to use R[0] instead of (reg R2).

    But the pass was taking the analogy too far, and was trying to simplify
    these fake sets based on costs.  That is, if there was an earlier:

      (set (reg T) A)

    the pass would go to considerable effort trying to work out whether:

      (set R[0] A)

    or:

      (set R[0] (reg T))

    was more profitable.  This included running validate*_change on the sets,
    which has no meaning given that the sets are not part of the insn.

    In this example, the equivalence A == T is already known, and the
    purpose of the fake sets is to add A == T == R[0].  We can do that
    just as easily (or, as the PR shows, more easily) if we keep the
    original form of the fake set, with A instead of T.

    The problem in the PR occurred if we had:

    (1) something that establishes an equivalence between a vector V1 of
        M-bit scalar integers and a hard register H

    (2) something that establishes an equivalence between a vector V2 of
        N-bit scalar integers, where N<M and where V2 contains at least 2
        instances of V1[0]

    (1) established an equivalence between V1[0] and H in M bits.
    (2) then triggered a search for an equivalence of V1[0] in N bits.
    This included:

          /* See if we have a CONST_INT that is already in a register in a
             wider mode.  */

    which (correctly) found that the low N bits of H contain the right value.
    But because it came from a wider mode, this equivalence between N-bit H
    and N-bit V1[0] was not yet in the hash table.  It therefore survived
    the purge in:

          /* At this point, ELT, if nonzero, points to a class of expressions
             equivalent to the source of this SET and SRC, SRC_EQV, SRC_FOLDED,
             and SRC_RELATED, if nonzero, each contain additional equivalent
             expressions.  Prune these latter expressions by deleting
expressions
             already in the equivalence class.

    And since more than 1 set found the same N-bit equivalence between
    H and V1[0], the pass tried to add it more than once.

    Things were already wrong at this stage, but an ICE was only triggered
    later when trying to merge this N-bit equivalence with another one.

    We could avoid the double registration by adding:

      for (elt = classp; elt; elt = elt->next_same_value)
        if (rtx_equal_p (elt->exp, x))
          return elt;

    to insert_with_costs, or by making cse_insn check whether previous
    sets have recorded the same equivalence.  The latter seems more
    appealing from a compile-time perspective.  But in this case,
    doing that would be adding yet more spurious work to the handling
    of fake sets.

    The handling of fake sets therefore seems like the more fundamental bug.

    While there, the patch also makes sure that we don't apply REG_EQUAL
    notes to these fake sets.  They only describe the "real" (first) set.

    gcc/
            PR rtl-optimization/111702
            * cse.cc (set::mode): Move earlier.
            (set::src_in_memory, set::src_volatile): Convert to bitfields.
            (set::is_fake_set): New member variable.
            (add_to_set): Add an is_fake_set parameter.
            (find_sets_in_insn): Update calls accordingly.
            (cse_insn): Do not apply REG_EQUAL notes to fake sets.  Do not
            try to optimize them either, or validate changes to them.

    gcc/testsuite/
            PR rtl-optimization/111702
            * gcc.dg/rtl/aarch64/pr111702.c: New test.

  parent reply	other threads:[~2023-12-20 19:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-05 12:34 [Bug rtl-optimization/111702] New: " zsojka at seznam dot cz
2023-10-06  7:48 ` [Bug rtl-optimization/111702] " rguenth at gcc dot gnu.org
2023-10-17 13:05 ` rguenth at gcc dot gnu.org
2023-11-10 17:41 ` jakub at gcc dot gnu.org
2023-11-10 17:46 ` prathamesh3492 at gcc dot gnu.org
2023-12-20 19:07 ` cvs-commit at gcc dot gnu.org [this message]
2023-12-20 19:08 ` rsandifo 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-111702-4-02jOYIM1NH@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).