* [Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
2021-12-09 11:08 [Bug target/103627] New: ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn) asolokha at gmx dot com
@ 2021-12-10 10:05 ` linkw at gcc dot gnu.org
2021-12-10 10:40 ` linkw at gcc dot gnu.org
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: linkw at gcc dot gnu.org @ 2021-12-10 10:05 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
2021-12-09 11:08 [Bug target/103627] New: ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn) asolokha at gmx dot com
2021-12-10 10:05 ` [Bug target/103627] " linkw at gcc dot gnu.org
@ 2021-12-10 10:40 ` linkw at gcc dot gnu.org
2021-12-20 5:20 ` linkw at gcc dot gnu.org
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: linkw at gcc dot gnu.org @ 2021-12-10 10:40 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
2021-12-09 11:08 [Bug target/103627] New: ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn) asolokha at gmx dot com
2021-12-10 10:05 ` [Bug target/103627] " linkw at gcc dot gnu.org
2021-12-10 10:40 ` linkw at gcc dot gnu.org
@ 2021-12-20 5:20 ` linkw at gcc dot gnu.org
2021-12-20 5:29 ` linkw at gcc dot gnu.org
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: linkw at gcc dot gnu.org @ 2021-12-20 5:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
2021-12-09 11:08 [Bug target/103627] New: ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn) asolokha at gmx dot com
` (2 preceding siblings ...)
2021-12-20 5:20 ` linkw at gcc dot gnu.org
@ 2021-12-20 5:29 ` linkw at gcc dot gnu.org
2022-02-07 5:48 ` cvs-commit at gcc dot gnu.org
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: linkw at gcc dot gnu.org @ 2021-12-20 5:29 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
2021-12-09 11:08 [Bug target/103627] New: ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn) asolokha at gmx dot com
` (3 preceding siblings ...)
2021-12-20 5:29 ` linkw at gcc dot gnu.org
@ 2022-02-07 5:48 ` cvs-commit at gcc dot gnu.org
2022-02-07 5:48 ` cvs-commit at gcc dot gnu.org
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-02-07 5:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
2021-12-09 11:08 [Bug target/103627] New: ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn) asolokha at gmx dot com
` (4 preceding siblings ...)
2022-02-07 5:48 ` cvs-commit at gcc dot gnu.org
@ 2022-02-07 5:48 ` cvs-commit at gcc dot gnu.org
2022-02-15 7:26 ` asolokha at gmx dot com
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-02-07 5:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
2021-12-09 11:08 [Bug target/103627] New: ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn) asolokha at gmx dot com
` (5 preceding siblings ...)
2022-02-07 5:48 ` cvs-commit at gcc dot gnu.org
@ 2022-02-15 7:26 ` asolokha at gmx dot com
2022-02-15 9:50 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: asolokha at gmx dot com @ 2022-02-15 7:26 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
2021-12-09 11:08 [Bug target/103627] New: ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn) asolokha at gmx dot com
` (6 preceding siblings ...)
2022-02-15 7:26 ` asolokha at gmx dot com
@ 2022-02-15 9:50 ` cvs-commit at gcc dot gnu.org
2022-02-15 9:50 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-02-15 9:50 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
2021-12-09 11:08 [Bug target/103627] New: ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn) asolokha at gmx dot com
` (7 preceding siblings ...)
2022-02-15 9:50 ` cvs-commit at gcc dot gnu.org
@ 2022-02-15 9:50 ` cvs-commit at gcc dot gnu.org
2022-02-15 9:51 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-02-15 9:50 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
2021-12-09 11:08 [Bug target/103627] New: ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn) asolokha at gmx dot com
` (8 preceding siblings ...)
2022-02-15 9:50 ` cvs-commit at gcc dot gnu.org
@ 2022-02-15 9:51 ` cvs-commit at gcc dot gnu.org
2022-02-15 9:51 ` cvs-commit at gcc dot gnu.org
2022-02-15 9:53 ` linkw at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-02-15 9:51 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
2021-12-09 11:08 [Bug target/103627] New: ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn) asolokha at gmx dot com
` (9 preceding siblings ...)
2022-02-15 9:51 ` cvs-commit at gcc dot gnu.org
@ 2022-02-15 9:51 ` cvs-commit at gcc dot gnu.org
2022-02-15 9:53 ` linkw at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-02-15 9:51 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
2021-12-09 11:08 [Bug target/103627] New: ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn) asolokha at gmx dot com
` (10 preceding siblings ...)
2022-02-15 9:51 ` cvs-commit at gcc dot gnu.org
@ 2022-02-15 9:53 ` linkw at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: linkw at gcc dot gnu.org @ 2022-02-15 9:53 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread