[Bug target/103627] New: ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)

[Bug target/103627] New: ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)

[asolokha at gmx dot com]

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

            Bug ID: 103627
           Summary: ICE: in extract_insn, at recog.c:2769 (error:
                    unrecognizable insn)
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: asolokha at gmx dot com
  Target Milestone: ---
            Target: powerpc-e300c3-linux-gnu

gcc 12.0.0 20211205 snapshot (g:c9419faef0bfaf31e6a6f744baa064892e0d105c) ICEs
when compiling gcc/testsuite/gcc.target/powerpc/pr102347.c w/o -mmma
-mcpu=power9:

% powerpc-e300c3-linux-gnu-gcc-12.0.0 -w -c
gcc/testsuite/gcc.target/powerpc/pr102347.c
gcc/testsuite/gcc.target/powerpc/pr102347.c: In function 'main':
gcc/testsuite/gcc.target/powerpc/pr102347.c:15:1: error: unrecognizable insn:
   15 | }
      | ^
(insn 14 18 15 2 (set (subreg:SI (reg:V16QI 130) 0)
        (subreg:SI (unspec:V16QI [
                    (reg:XO 118 [ _4 ])
                    (const_int 0 [0])
                ] UNSPEC_MMA_EXTRACT) 0)) -1
     (nil))
during RTL pass: vregs
gcc/testsuite/gcc.target/powerpc/pr102347.c:15:1: internal compiler error: in
extract_insn, at recog.c:2769
0x6ac6f5 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/rtl-error.c:108
0x6ac715 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/rtl-error.c:116
0x6aad23 extract_insn(rtx_insn*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/recog.c:2769
0xb253f3 instantiate_virtual_regs_in_insn
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/function.c:1611
0xb253f3 instantiate_virtual_regs
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/function.c:1985
0xb253f3 execute
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/function.c:2034

[Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2021-12-10
                 CC|                            |bergner at gcc dot gnu.org,
                   |                            |linkw at gcc dot gnu.org,
                   |                            |segher at gcc dot gnu.org,
                   |                            |wschmidt at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |linkw at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Kewen Lin <linkw at gcc dot gnu.org> ---
I'll have a look.

[Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)

[linkw at gcc dot gnu.org]

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

--- Comment #2 from Kewen Lin <linkw at gcc dot gnu.org> ---
Confirmed.  But even if I reverted my previous commit r12-5590 which introduced
this test case (from PR102347) into testsuites, this ICE still exists. So it's
not a regression related to the commit but a latent issue.

I can see the same ICE on BE with -m32 -mcpu=powerpc (or -mcpu=powerpc64).

[Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)

[linkw at gcc dot gnu.org]

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

--- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---
Also failed with r12-0.

I looked into the ICE with -mcpu=power6 -m32 on BE, the direct reason is that
we turn off VSX flag but still leave MMA, when it wants to emit one move for
V16QI it has to use multiple word way, the generated insns are not recognized.

The reason why it turn off VSX is that TARGET_AVOID_XFORM enabled by power6:

      else if (TARGET_AVOID_XFORM > 0)
        msg = N_("%<-mvsx%> needs indexed addressing");

      if (msg)
        {
          warning (0, msg);
          rs6000_isa_flags &= ~ OPTION_MASK_VSX;
          rs6000_isa_flags_explicit |= OPTION_MASK_VSX;
        }

I think we should check P9 vector here since Power9 supports DQ-form vector
storage access.

Even I hacked it, it will still turn off VSX in the hunk:

  /* Disable VSX and Altivec silently if the user switched cpus to power7 in a
     target attribute or pragma which automatically enables both options,
     unless the altivec ABI was set.  This is set by default for 64-bit, but
     not for 32-bit.  */
  if (main_target_opt != NULL && !main_target_opt->x_rs6000_altivec_abi)
    {
      TARGET_FLOAT128_TYPE = 0;
      rs6000_isa_flags &= ~((OPTION_MASK_VSX | OPTION_MASK_ALTIVEC
                             | OPTION_MASK_FLOAT128_KEYWORD)
                            & ~rs6000_isa_flags_explicit);
    }

I think it's expected because the quoted ABI change.

So the question is that when we disable VSX, can we still allow MMA?

As searching in ISA3.1, it says: "SIMD is a requirement for MMA." So I think
the answer is no.  Not sure why we don't have one option P10 VECTOR like
existing P8 and P9 VECTOR, I'm going to use P9 VECTOR as one guard for MMA for
now.

[Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)

[linkw at gcc dot gnu.org]

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

--- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> ---
For test.c, even we are on ppc64le P9, it can also get ICE:

extern float *dest;
extern __vector_quad src;

int
foo ()
{
  __builtin_mma_disassemble_acc (dest, &src);
  return 0;
}


$ gcc test.c -mcpu=power10 -mno-vsx

test.c: In function ‘foo’:
test.c:14:1: error: insn does not satisfy its constraints:
   14 | }
      | ^
(insn 55 7 56 (set (reg:OO 34 2)
        (mem/c:OO (reg/f:DI 10 10 [127]) [2 src+0 S32 A512])) "test.c":10:1
2128 {*movoo}
     (nil))
during RTL pass: shorten
test.c:14:1: internal compiler error: in extract_constrain_insn_cached, at
recog.c:2682

[Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:8103623923ac4ea19b97a369979d4bd5731aab57

commit r12-7078-g8103623923ac4ea19b97a369979d4bd5731aab57
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Sun Feb 6 21:29:32 2022 -0600

    rs6000: Disable MMA if no VSX support [PR103627]

    As PR103627 shows, there is an unexpected case where !TARGET_VSX
    and TARGET_MMA co-exist.  As ISA3.1 claims, SIMD is a requirement
    for MMA.  By looking into the ICE, I noticed that the current
    MMA implementation depends on vector pairs load/store which use
    VSX register, but we don't have a separated option to control
    Power10 vector support and Segher pointed out "-mpower9-vector is
    a workaround that should go away" and more explanations in [1].
    So this patch makes MMA require VSX instead.

    [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589303.html

    gcc/ChangeLog:

            PR target/103627
            * config/rs6000/rs6000.cc (rs6000_option_override_internal):
Disable
            MMA if !TARGET_VSX.

    gcc/testsuite/ChangeLog:

            PR target/103627
            * gcc.target/powerpc/pr103627-1.c: New test.
            * gcc.target/powerpc/pr103627-2.c: New test.

[Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:e66ba0f55c000152df63fc67c11a64f79122ef86

commit r12-7079-ge66ba0f55c000152df63fc67c11a64f79122ef86
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Sun Feb 6 21:30:02 2022 -0600

    rs6000: Move the hunk affecting VSX/ALTIVEC ahead [PR103627]

    The modified hunk can update VSX and ALTIVEC flag, we have some codes
    to check/warn for some flags related to VSX and ALTIVEC sitting where
    the hunk is proprosed to be moved to.  Without this adjustment, the
    VSX and ALTIVEC update is too late, it can cause the incompatibility
    and result in unexpected behaviors, the associated test case is one
    typical case.

    Since we already have the code which sets TARGET_FLOAT128_TYPE and lays
    after the moved place, and OPTION_MASK_FLOAT128_KEYWORD will rely on
    TARGET_FLOAT128_TYPE, so it just simply remove them.

    gcc/ChangeLog:

            PR target/103627
            * config/rs6000/rs6000.cc (rs6000_option_override_internal): Move
the
            hunk affecting VSX and ALTIVEC to appropriate place.

    gcc/testsuite/ChangeLog:

            PR target/103627
            * gcc.target/powerpc/pr103627-3.c: New test.

[Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)

[asolokha at gmx dot com]

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

--- Comment #7 from Arseny Solokha <asolokha at gmx dot com> ---
Should this PR be closed, or are there backports pending?

[Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:b1ca2019a828d60d8c447b5af0514f0e8ea63654

commit r11-9571-gb1ca2019a828d60d8c447b5af0514f0e8ea63654
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Sun Feb 6 21:29:32 2022 -0600

    rs6000: Disable MMA if no VSX support [PR103627]

    As PR103627 shows, there is an unexpected case where !TARGET_VSX
    and TARGET_MMA co-exist.  As ISA3.1 claims, SIMD is a requirement
    for MMA.  By looking into the ICE, I noticed that the current
    MMA implementation depends on vector pairs load/store which use
    VSX register, but we don't have a separated option to control
    Power10 vector support and Segher pointed out "-mpower9-vector is
    a workaround that should go away" and more explanations in [1].
    So this patch makes MMA require VSX instead.

    [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589303.html

    gcc/ChangeLog:

            PR target/103627
            * config/rs6000/rs6000.c (rs6000_option_override_internal): Disable
            MMA if !TARGET_VSX.

    gcc/testsuite/ChangeLog:

            PR target/103627
            * gcc.target/powerpc/pr103627-1.c: New test.
            * gcc.target/powerpc/pr103627-2.c: New test.

    (cherry picked from commit 8103623923ac4ea19b97a369979d4bd5731aab57)

[Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:2c9485a496f2faa294e7849a1d9c582c015605cc

commit r11-9572-g2c9485a496f2faa294e7849a1d9c582c015605cc
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Sun Feb 6 21:30:02 2022 -0600

    rs6000: Move the hunk affecting VSX/ALTIVEC ahead [PR103627]

    The modified hunk can update VSX and ALTIVEC flag, we have some codes
    to check/warn for some flags related to VSX and ALTIVEC sitting where
    the hunk is proprosed to be moved to.  Without this adjustment, the
    VSX and ALTIVEC update is too late, it can cause the incompatibility
    and result in unexpected behaviors, the associated test case is one
    typical case.

    Since we already have the code which sets TARGET_FLOAT128_TYPE and lays
    after the moved place, and OPTION_MASK_FLOAT128_KEYWORD will rely on
    TARGET_FLOAT128_TYPE, so it just simply remove them.

    gcc/ChangeLog:

            PR target/103627
            * config/rs6000/rs6000.c (rs6000_option_override_internal): Move
the
            hunk affecting VSX and ALTIVEC to appropriate place.

    gcc/testsuite/ChangeLog:

            PR target/103627
            * gcc.target/powerpc/pr103627-3.c: New test.

    (cherry picked from commit e66ba0f55c000152df63fc67c11a64f79122ef86)

[Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:7ed740240657cc35f02130a412938d209ff24496

commit r10-10456-g7ed740240657cc35f02130a412938d209ff24496
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Sun Feb 6 21:29:32 2022 -0600

    rs6000: Disable MMA if no VSX support [PR103627]

    As PR103627 shows, there is an unexpected case where !TARGET_VSX
    and TARGET_MMA co-exist.  As ISA3.1 claims, SIMD is a requirement
    for MMA.  By looking into the ICE, I noticed that the current
    MMA implementation depends on vector pairs load/store which use
    VSX register, but we don't have a separated option to control
    Power10 vector support and Segher pointed out "-mpower9-vector is
    a workaround that should go away" and more explanations in [1].
    So this patch makes MMA require VSX instead.

    [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589303.html

    gcc/ChangeLog:

            PR target/103627
            * config/rs6000/rs6000.c (rs6000_option_override_internal): Disable
            MMA if !TARGET_VSX.

    gcc/testsuite/ChangeLog:

            PR target/103627
            * gcc.target/powerpc/pr103627-1.c: New test.
            * gcc.target/powerpc/pr103627-2.c: New test.

    (cherry picked from commit 8103623923ac4ea19b97a369979d4bd5731aab57)

[Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:99ac7ce34348889125230687d8277cd1df22027a

commit r10-10457-g99ac7ce34348889125230687d8277cd1df22027a
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Sun Feb 6 21:30:02 2022 -0600

    rs6000: Move the hunk affecting VSX/ALTIVEC ahead [PR103627]

    The modified hunk can update VSX and ALTIVEC flag, we have some codes
    to check/warn for some flags related to VSX and ALTIVEC sitting where
    the hunk is proprosed to be moved to.  Without this adjustment, the
    VSX and ALTIVEC update is too late, it can cause the incompatibility
    and result in unexpected behaviors, the associated test case is one
    typical case.

    Since we already have the code which sets TARGET_FLOAT128_TYPE and lays
    after the moved place, and OPTION_MASK_FLOAT128_KEYWORD will rely on
    TARGET_FLOAT128_TYPE, so it just simply remove them.

    gcc/ChangeLog:

            PR target/103627
            * config/rs6000/rs6000.c (rs6000_option_override_internal): Move
the
            hunk affecting VSX and ALTIVEC to appropriate place.

    gcc/testsuite/ChangeLog:

            PR target/103627
            * gcc.target/powerpc/pr103627-3.c: New test.

    (cherry picked from commit e66ba0f55c000152df63fc67c11a64f79122ef86)

[Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

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

--- Comment #12 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Arseny Solokha from comment #7)
> Should this PR be closed, or are there backports pending?

Yeah, it waits for backporting. Trunk and all affected branches should be fixed
now.