[Bug rtl-optimization/106303] New: ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791

[Bug rtl-optimization/106303] New: ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791

[zhendong.su at inf dot ethz.ch]

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

            Bug ID: 106303
           Summary: ICE on valid code at -O3 with
                    -fno-inline-small-functions on x86_64-linux-gnu: in
                    extract_insn, at recog.cc:2791
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[557] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-sanitizers
--enable-languages=c,c++ --disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220714 (experimental) [master r13-1696-g29f40a8047f] (GCC)
[558] %
[558] % gcctk -O3 -fno-inline-small-functions small.c
small.c: In function ‘k’:
small.c:17:1: error: unrecognizable insn:
   17 | }
      | ^
(insn 55 58 66 7 (set (reg:V1TI 90 [ D.2002 ])
        (mem/c:TI (symbol_ref:DI ("j") [flags 0x2] <var_decl 0x7ff1682b7c60 j>)
[2 j+0 S16 A128])) -1
     (nil))
during RTL pass: subreg3
small.c:17:1: internal compiler error: in extract_insn, at recog.cc:2791
0x722c42 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
        ../../gcc-trunk/gcc/rtl-error.cc:108
0x722c5e _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        ../../gcc-trunk/gcc/rtl-error.cc:116
0x721191 extract_insn(rtx_insn*)
        ../../gcc-trunk/gcc/recog.cc:2791
0x1d4e347 decompose_multiword_subregs
        ../../gcc-trunk/gcc/lower-subreg.cc:1555
0x1d4f1cd execute
        ../../gcc-trunk/gcc/lower-subreg.cc:1820
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[559] %
[559] % cat small.c
struct a {
  int b;
  int c;
  int d;
  int e;
} i, j;
int f, g, h;
struct a k() {
  while (f)
    i = j;
  if (g) {
    for (; h; h++)
      i = j;
    return j;
  }
  return i;
}
int main() {
  k();
  return 0;
}

[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |13.0
   Target Milestone|---                         |13.0
            Summary|ICE on valid code at -O3    |[13 Regression] ICE on
                   |with                        |valid code at -O3 with
                   |-fno-inline-small-functions |-fno-inline-small-functions
                   |on x86_64-linux-gnu: in     |on x86_64-linux-gnu: in
                   |extract_insn, at            |extract_insn, at
                   |recog.cc:2791               |recog.cc:2791
             Target|                            |x86_64-linux-gnu

[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-07-15
                 CC|                            |marxin at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
            Summary|[13 Regression] ICE on      |[13 Regression] ICE on
                   |valid code at -O3 with      |valid code at -O3 with
                   |-fno-inline-small-functions |-fno-inline-small-functions
                   |on x86_64-linux-gnu: in     |on x86_64-linux-gnu: in
                   |extract_insn, at            |extract_insn, at
                   |recog.cc:2791               |recog.cc:2791 since
                   |                            |r13-1607-gc3ed9e0d6e96d869

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r13-1607-gc3ed9e0d6e96d869.

[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869

[roger at nextmovesoftware dot com]

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

--- Comment #2 from Roger Sayle <roger at nextmovesoftware dot com> ---
Grr... This problem is at (currently just beyond) the limits of my abilities. 
The TImode STV pass uses data flow to split conversion opportunities up into
chains, effectively performing live range splitting, as some of uses/defs of a
pseudo register may be in one chain, and other (independent) uses/defs of that
pseudo in another chain.  In the case reported in the PR, this results in some
occurences of (reg 90) being converted to V1TImode, and other occurrences
remaining in TImode.  Worse, thanks to RTL sharing, calling PUT_MODE on a
register in one chain, implicitly affects the mode of that register in other
chains/insns.  I must admit that I'd assumed that either all instances of a
pseudo (like (reg 90)) either get converted or all don't get converted [i.e.
chains ~ pseudos].  Fixing this will require either some form of regno mapping
or unsharing... (or??).

I'll continue investigating, but if anyone can see/knows the correct way to fix
this, please do let me know.

[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869

[roger at nextmovesoftware dot com]

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

--- Comment #3 from Roger Sayle <roger at nextmovesoftware dot com> ---
I think the solution may be similar/related to Richard Biener's fix for PR
target/91522.

[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869

[zhendong.su at inf dot ethz.ch]

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

--- Comment #4 from Zhendong Su <zhendong.su at inf dot ethz.ch> ---
Here is another repro that ICEs at -O2 (without -fno-inline-small-functions).

[570] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-sanitizers
--enable-languages=c,c++ --disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220717 (experimental) [master r13-1722-g7bcd7f47359] (GCC)
[571] %
[571] % gcctk -O2 small.c
small.c: In function ‘n’:
small.c:18:1: error: unrecognizable insn:
   18 | }
      | ^
(insn 41 25 32 8 (set (reg:TI 85 [ D.2008 ])
        (reg:V1TI 90 [ D.2008 ])) "small.c":16:12 -1
     (expr_list:REG_DEAD (reg:V1TI 90 [ D.2008 ])
        (expr_list:REG_EQUAL (mem/c:TI (symbol_ref:DI ("k") [flags 0x2]
<var_decl 0x7f279eb4acf0 k>) [2 k+0 S16 A128])  
            (nil))))
during RTL pass: subreg3
small.c:18:1: internal compiler error: in extract_insn, at recog.cc:2791
0x722ccc _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
        ../../gcc-trunk/gcc/rtl-error.cc:108
0x722ce8 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        ../../gcc-trunk/gcc/rtl-error.cc:116
0x72121b extract_insn(rtx_insn*)
        ../../gcc-trunk/gcc/recog.cc:2791
0x1d4e697 decompose_multiword_subregs
        ../../gcc-trunk/gcc/lower-subreg.cc:1555
0x1d4f51d execute
        ../../gcc-trunk/gcc/lower-subreg.cc:1820
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[572] %
[572] % cat small.c
struct a {
  int b;
  int c;
  int d;
  int e;
} i, j, k, l;
int f, g, h;
static struct a n() {
  if (f)
    while (1)
      i = k;
  j = k;
  for (; g; g++)
    ;
  if (h)
    return k;
  return j;
}
void o() { l = n(); }
int main() {
  o();
  return 0;
}

[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |roger at nextmovesoftware dot com

[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
The original TImode STV pass only converts load and store.  When other
operations were added, timode_remove_non_convertible_regs no longer works
correctly. After an instruction is removed from the candidate list, any
instructions which use the associated registers should also be removed
from the candidate list.

[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 53326
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53326&action=edit
Something like this

[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zsojka at seznam dot cz

--- Comment #7 from Roger Sayle <roger at nextmovesoftware dot com> ---
*** Bug 106404 has been marked as a duplicate of this bug. ***

[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869

[roger at nextmovesoftware dot com]

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

--- Comment #8 from Roger Sayle <roger at nextmovesoftware dot com> ---
*** Bug 106407 has been marked as a duplicate of this bug. ***

[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

https://gcc.gnu.org/g:76d6224b944e1a66bfb1195fb7d35d9726f1aed8

commit r13-1811-g76d6224b944e1a66bfb1195fb7d35d9726f1aed8
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Sun Jul 24 12:22:22 2022 +0100

    PR target/106303: Fix TImode STV related failures on x86.

    This patch resolves PR target/106303 (and the related PRs 106347,
    106404, 106407) which are ICEs caused by my improvements to x86_64's
    128-bit TImode to V1TImode Scalar to Vector (STV) pass.  My apologies
    for the breakage.  The issue is that data flow analysis is used to
    partition usage of each TImode pseudo into "chains", where each
    chain is analyzed and if suitable converted to vector operations.
    The problems appears when some chains for a pseudo are converted,
    and others aren't as RTL sharing can result in some mode changes
    leaking into other instructions that aren't/shouldn't/can't be
    converted, which eventually leads to an ICE for mismatched modes.

    My first approach to a fix was to unify more of the STV infrastructure,
    reasoning that if TImode STV was exhibiting these problems, but DImode
    and SImode STV weren't, the issue was likely to be caused/resolved by
    these remaining differences.  This appeared to fix some but not all of
    the reported PRs.  A better solution was then proposed by H.J. Lu in
    Bugzilla, that we need to iterate the removal of candidates in the
    function timode_remove_non_convertible_regs until there are no further
    changes.  As each chain is removed from consideration, it in turn may
    affect whether other insns/chains can safely be converted.

    2022-07-24  Roger Sayle  <roger@nextmovesoftware.com>
                H.J. Lu  <hjl.tools@gmail.com>

    gcc/ChangeLog
            PR target/106303
            PR target/106347
            * config/i386/i386-features.cc (make_vector_copies): Move from
            general_scalar_chain to scalar_chain.
            (convert_reg): Likewise.
            (convert_insn_common): New scalar_chain method split out from
            general_scalar_chain convert_insn.
            (convert_registers): Move from general_scalar_chain to
            scalar_chain.
            (scalar_chain::convert): Call convert_insn_common before calling
            convert_insn.
            (timode_remove_non_convertible_regs): Iterate until there are
            no further changes to the candidates.
            * config/i386/i386-features.h (scalar_chain::hash_map): Move
            from general_scalar_chain.
            (scalar_chain::convert_reg): Likewise.
            (scalar_chain::convert_insn_common): New shared method.
            (scalar_chain::make_vector_copies): Move from general_scalar_chain.
            (scalar_chain::convert_registers): Likewise.  No longer virtual.
            (general_scalar_chain::hash_map): Delete.  Moved to scalar_chain.
            (general_scalar_chain::convert_reg): Likewise.
            (general_scalar_chain::make_vector_copies): Likewise.
            (general_scalar_chain::convert_registers): Delete virtual method.
            (timode_scalar_chain::convert_registers): Likewise.

    gcc/testsuite/ChangeLog
            PR target/106303
            PR target/106347
            * gcc.target/i386/pr106303.c: New test case.
            * gcc.target/i386/pr106347.c: New test case.

[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #10 from Roger Sayle <roger at nextmovesoftware dot com> ---
This should now be fixed on mainline.