public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/106933] New: [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn)
@ 2022-09-13 18:49 asolokha at gmx dot com
2022-09-13 19:23 ` [Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92 marxin at gcc dot gnu.org
` (10 more replies)
0 siblings, 11 replies; 12+ messages in thread
From: asolokha at gmx dot com @ 2022-09-13 18:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
Bug ID: 106933
Summary: [13 Regression] ICE in extract_insn, at recog.cc:2791
(error: unrecognizable insn)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc 13.0.0 20220911 snapshot (g:0ea5e3f4542832b8da016b152695e64a2a386309) ICEs
when compiling the following testcase w/ -O2:
short int
bar (void);
__int128
empty (void)
{
}
__attribute__ ((simd)) int
foo (__int128 *p)
{
int a = 0x80000000;
*p = empty ();
return *p == (a < bar ());
}
% x86_64-unknown-linux-gnu-gcc-13.0.0 -O2 -c ylbcgrld.c
ylbcgrld.c: In function 'foo.simdclone.2':
ylbcgrld.c:17:1: error: unrecognizable insn:
17 | }
| ^
(insn 73 72 74 3 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:V1TI 20 xmm0 [orig:82 D.2028 ] [82])
(const_int 1 [0x1]))) "ylbcgrld.c":16:13 -1
(expr_list:REG_DEAD (reg:V1TI 20 xmm0 [orig:82 D.2028 ] [82])
(nil)))
during RTL pass: cprop_hardreg
ylbcgrld.c:17:1: internal compiler error: in extract_insn, at recog.cc:2791
0x730822 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/rtl-error.cc:108
0x73083e _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/rtl-error.cc:116
0x72edc3 extract_insn(rtx_insn*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/recog.cc:2791
0xe4dc0b extract_constrain_insn(rtx_insn*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/recog.cc:2690
0xe58de6 copyprop_hardreg_forward_1
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/regcprop.cc:826
0xe59fbf execute
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/regcprop.cc:1408
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92
2022-09-13 18:49 [Bug target/106933] New: [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) asolokha at gmx dot com
@ 2022-09-13 19:23 ` marxin at gcc dot gnu.org
2022-09-14 6:25 ` rguenth at gcc dot gnu.org
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: marxin at gcc dot gnu.org @ 2022-09-13 19:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |marxin at gcc dot gnu.org,
| |sayle at gcc dot gnu.org
Summary|[13 Regression] ICE in |[13 Regression] ICE in
|extract_insn, at |extract_insn, at
|recog.cc:2791 (error: |recog.cc:2791 (error:
|unrecognizable insn) |unrecognizable insn) since
| |r13-2049-g6f94923dea21bd92
Last reconfirmed| |2022-09-13
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Started since r13-2049-g6f94923dea21bd92.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92
2022-09-13 18:49 [Bug target/106933] New: [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) asolokha at gmx dot com
2022-09-13 19:23 ` [Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92 marxin at gcc dot gnu.org
@ 2022-09-14 6:25 ` rguenth at gcc dot gnu.org
2022-09-14 11:39 ` roger at nextmovesoftware dot com
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-09-14 6:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |13.0
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92
2022-09-13 18:49 [Bug target/106933] New: [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) asolokha at gmx dot com
2022-09-13 19:23 ` [Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92 marxin at gcc dot gnu.org
2022-09-14 6:25 ` rguenth at gcc dot gnu.org
@ 2022-09-14 11:39 ` roger at nextmovesoftware dot com
2022-09-14 12:35 ` roger at nextmovesoftware dot com
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: roger at nextmovesoftware dot com @ 2022-09-14 11:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
Roger Sayle <roger at nextmovesoftware dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |roger at nextmovesoftware dot com
--- Comment #2 from Roger Sayle <roger at nextmovesoftware dot com> ---
Something very odd is going on. foo.simdclone.2 contains a *cmpti_doubleword
instruction, that is defined using define_insn_and_split to be split
pre-reload.
For some reason, this isn't getting split during the split1 pass, but continues
through reload until things finally fail in cprop_hardreg. Interestingly the
corresponding instruction is correctly split in simdclone.0 and simdclone.1.
The .293e.split1 file contains (much redacted)...
;; Function foo.simdclone.0
Splitting with gen_split_2 (i386.md:1511)
deleting insn with uid = 16.
;; Function foo.simdclone.1
Splitting with gen_split_2 (i386.md:1511)
deleting insn with uid = 22.
;; Function foo.simdclone.2
i.e. no splits are performed on foo.simdclone.2, but they are on simdclone.0
and simdclone.1. Perhaps an off-by-one error? I'll investigate further, but I
doubt this is an issue in the i386.md machine description; the ((simd))
attribute is interacting strangely with the split pass.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92
2022-09-13 18:49 [Bug target/106933] New: [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) asolokha at gmx dot com
` (2 preceding siblings ...)
2022-09-14 11:39 ` roger at nextmovesoftware dot com
@ 2022-09-14 12:35 ` roger at nextmovesoftware dot com
2022-10-06 16:03 ` asolokha at gmx dot com
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: roger at nextmovesoftware dot com @ 2022-09-14 12:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
--- Comment #3 from Roger Sayle <roger at nextmovesoftware dot com> ---
Ignore all of Comment 2. The reason the instruction isn't getting split, is
that (unlike the other clones), the pseudo's mode is V1TI (not TI), hence
doesn't match the <DWI> constraint. The problem is STV (again), where uses of
a pseudo are split into different chains, and some chains are considered
profitable, and other chains aren't supported in V1TImode.
Searching for mode conversion candidates...
insn 13 is marked as a TImode candidate
insn 16 is marked as a TImode candidate
Created a new instruction chain #7
Building chain #7...
Adding insn 13 to chain #7
Collected chain #7...
insns: 13
Computing gain for chain #7...
Instruction gain 4 for 13: [r91:DI]=r82:TI
REG_DEAD r91:DI
Total gain: 5
Converting chain #7...
deferring rescan insn with uid = 13.
Created a new instruction chain #8
Building chain #8...
Adding insn 16 to chain #8
Collected chain #8...
insns: 16
Computing gain for chain #8...
Instruction gain -4 for 16: flags:CCZ=cmp(r82:V1TI,0x1)
REG_DEAD r82:V1TI
Total gain: -3
Chain #8 conversion is not profitable
Total insns converted: 1
The issue is that you can't convert insn 13 to V1TImode if you don't convert
insn 16, i.e. all uses of a pseudo should have the same mode. [Calling
PUT_MODE on the first use, implicitly updates the second]. I believe (this
time) that the uninitialized value from "empty()" confuses that DF analysis,
and insns 13 and 16 end up on different (dependency) chains, because the lack
on initialization makes them look independent.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92
2022-09-13 18:49 [Bug target/106933] New: [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) asolokha at gmx dot com
` (3 preceding siblings ...)
2022-09-14 12:35 ` roger at nextmovesoftware dot com
@ 2022-10-06 16:03 ` asolokha at gmx dot com
2022-10-06 17:18 ` hjl.tools at gmail dot com
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: asolokha at gmx dot com @ 2022-10-06 16:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
--- Comment #4 from Arseny Solokha <asolokha at gmx dot com> ---
JFTR, I've just got an ICE that I presume to be another manifestation of the
same issue. The current gcc trunk snapshots ICE the way reported in comment 0
on the following testcase w/ -msse4 -Os:
__int128 n;
__int128
empty (void)
{
}
int
foo (void)
{
n = empty ();
return n == 0;
}
while replacing the last return statement w/ "return n == 1;" gives the
following:
% x86_64-unknown-linux-gnu-gcc-13.0.0 -msse4 -Os -c lr4kukze.c
during RTL pass: cse2
lr4kukze.c: In function 'foo':
lr4kukze.c:14:1: internal compiler error: in as_a, at machmode.h:365
14 | }
| ^
0x73665b scalar_int_mode as_a<scalar_int_mode>(machine_mode)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/machmode.h:365
0x736783 scalar_mode as_a<scalar_mode>(machine_mode)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/rtl.h:2288
0x736783 wi::int_traits<std::pair<rtx_def*, machine_mode>
>::get_precision(std::pair<rtx_def*, machine_mode> const&)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/rtl.h:2273
0x736783 unsigned int wi::get_precision<std::pair<rtx_def*, machine_mode>
>(std::pair<rtx_def*, machine_mode> const&)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/wide-int.h:1794
0x736783 wide_int_ref_storage<false,
false>::wide_int_ref_storage<std::pair<rtx_def*, machine_mode>
>(std::pair<rtx_def*, machine_mode> const&)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/wide-int.h:1024
0x736783 generic_wide_int<wide_int_ref_storage<false, false>
>::generic_wide_int<std::pair<rtx_def*, machine_mode> >(std::pair<rtx_def*,
machine_mode> const&)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/wide-int.h:782
0x736783 poly_int<1u, generic_wide_int<wide_int_ref_storage<false, false> >
>::poly_int<std::pair<rtx_def*, machine_mode> >(std::pair<rtx_def*,
machine_mode> const&)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/poly-int.h:670
0x736783 wi::to_poly_wide(rtx_def const*, machine_mode)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/rtl.h:2373
0x736783 neg_poly_int_rtx
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/simplify-rtx.cc:57
0xec311e simplify_context::simplify_binary_operation_1(rtx_code, machine_mode,
rtx_def*, rtx_def*, rtx_def*, rtx_def*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/simplify-rtx.cc:3118
0xec501d simplify_context::simplify_binary_operation(rtx_code, machine_mode,
rtx_def*, rtx_def*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/simplify-rtx.cc:2626
0xed00c2 simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/rtl.h:3475
0xed00c2 simplify_const_relational_operation(rtx_code, machine_mode, rtx_def*,
rtx_def*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/simplify-rtx.cc:6112
0xec948b simplify_context::simplify_relational_operation(rtx_code,
machine_mode, machine_mode, rtx_def*, rtx_def*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/simplify-rtx.cc:5704
0x1cfed28 simplify_relational_operation(rtx_code, machine_mode, machine_mode,
rtx_def*, rtx_def*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/rtl.h:3490
0x1cfed28 fold_rtx
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cse.cc:3385
0x1cfffb3 cse_insn
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cse.cc:4669
0x1d04e24 cse_extended_basic_block
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cse.cc:6566
0x1d04e24 cse_main
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cse.cc:6711
0x1d05750 rest_of_handle_cse2
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cse.cc:7600
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92
2022-09-13 18:49 [Bug target/106933] New: [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) asolokha at gmx dot com
` (4 preceding siblings ...)
2022-10-06 16:03 ` asolokha at gmx dot com
@ 2022-10-06 17:18 ` hjl.tools at gmail dot com
2022-10-18 8:45 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: hjl.tools at gmail dot com @ 2022-10-06 17:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hjl.tools at gmail dot com
--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
This fixes ICE:
diff --git a/gcc/config/i386/i386-features.cc
b/gcc/config/i386/i386-features.cc
index fd212262f50..cc690a6064c 100644
--- a/gcc/config/i386/i386-features.cc
+++ b/gcc/config/i386/i386-features.cc
@@ -1975,6 +1975,9 @@ timode_scalar_to_vector_candidate_p (rtx_insn *insn)
switch (GET_CODE (src))
{
case REG:
+ /* Return false if the source is uninitialized. */
+ return DF_REG_DEF_CHAIN (REGNO (src)) != nullptr;
+
case CONST_WIDE_INT:
return true;
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92
2022-09-13 18:49 [Bug target/106933] New: [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) asolokha at gmx dot com
` (5 preceding siblings ...)
2022-10-06 17:18 ` hjl.tools at gmail dot com
@ 2022-10-18 8:45 ` rguenth at gcc dot gnu.org
2022-10-21 18:53 ` hjl.tools at gmail dot com
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-10-18 8:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92
2022-09-13 18:49 [Bug target/106933] New: [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) asolokha at gmx dot com
` (6 preceding siblings ...)
2022-10-18 8:45 ` rguenth at gcc dot gnu.org
@ 2022-10-21 18:53 ` hjl.tools at gmail dot com
2022-12-01 12:49 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: hjl.tools at gmail dot com @ 2022-10-21 18:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
This
diff --git a/gcc/config/i386/i386-features.cc
b/gcc/config/i386/i386-features.cc
index e357294bc4e..aca34d730a8 100644
--- a/gcc/config/i386/i386-features.cc
+++ b/gcc/config/i386/i386-features.cc
@@ -1449,6 +1449,9 @@ timode_scalar_chain::compute_convert_gain ()
break;
case COMPARE:
+ if (REG_P (XEXP (src, 0))
+ && GET_MODE (XEXP (src, 0)) == V1TImode)
+ return 1;
if (XEXP (src, 1) == const0_rtx)
{
if (GET_CODE (XEXP (src, 0)) == AND)
also works.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92
2022-09-13 18:49 [Bug target/106933] New: [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) asolokha at gmx dot com
` (7 preceding siblings ...)
2022-10-21 18:53 ` hjl.tools at gmail dot com
@ 2022-12-01 12:49 ` jakub at gcc dot gnu.org
2022-12-23 9:52 ` cvs-commit at gcc dot gnu.org
2022-12-24 17:16 ` roger at nextmovesoftware dot com
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-01 12:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
URL| |https://gcc.gnu.org/piperma
| |il/gcc-patches/2022-October
| |/604743.html
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Have you pinged your patch (and CCed Uros)?
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92
2022-09-13 18:49 [Bug target/106933] New: [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) asolokha at gmx dot com
` (8 preceding siblings ...)
2022-12-01 12:49 ` jakub at gcc dot gnu.org
@ 2022-12-23 9:52 ` cvs-commit at gcc dot gnu.org
2022-12-24 17:16 ` roger at nextmovesoftware dot com
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-12-23 9:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
--- Comment #8 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:24a7980d0f48671ea13da18c9162a43420b5af58
commit r13-4872-g24a7980d0f48671ea13da18c9162a43420b5af58
Author: Roger Sayle <roger@nextmovesoftware.com>
Date: Fri Dec 23 09:50:18 2022 +0000
PR target/106933: Limit TImode STV to SSA-like def-use chains on x86.
With many thanks to H.J. for doing all the hard work, this patch resolves
two P1 regressions; PR target/106933 and PR target/106959.
Although superficially similar, the i386 backend's two scalar-to-vector
(STV) passes perform their transformations in importantly different ways.
The original pass converting SImode and DImode operations to V4SImode
or V2DImode operations is "soft", allowing values to be maintained in
both integer and vector hard registers. The newer pass converting TImode
operations to V1TImode is "hard" (all or nothing) that converts all uses
of a pseudo to vector form. To implement this it invokes powerful ju-ju
calling SET_MODE on a reg_rtx, which due to RTL sharing, often updates
this pseudo's mode everywhere in the RTL chain. Hence, TImode STV can only
be performed when all uses of a pseudo are convertible to V1TImode form.
To ensure this the STV passes currently use data-flow analysis to inspect
all DEFs and USEs in a chain. This works fine for chains that are in
the usual single assignment form, but the occurrence of uninitialized
variables, or multiple assignments that split a pseudo's usage into
several independent chains (lifetimes) can lead to situations where
some but not all of a pseudo's occurrences need to be updated. This is
safe for the SImode/DImode pass, but leads to the above bugs during
the TImode pass.
My one minor tweak to HJ's patch from comment #4 of bugzilla PR106959
is to only perform the new single_def_chain_p check for TImode STV; it
turns out that STV of SImode/DImode min/max operates safely on multiple-def
chains, and prohibiting this leads to testsuite regressions. We don't
(yet) support V1TImode min/max, so this idiom isn't an issue during the
TImode STV pass.
For the record, the two alternate possible fixes are (i) make the TImode
STV pass "soft", by eliminating use of SET_MODE, instead using replace_rtx
with a new pseudo, or (ii) merging "chains" so that multiple DFA
chains/lifetimes are considered a single STV chain.
2022-12-23 H.J. Lu <hjl.tools@gmail.com>
Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR target/106933
PR target/106959
* config/i386/i386-features.cc (single_def_chain_p): New predicate
function to check that a pseudo's use-def chain is in SSA form.
(timode_scalar_to_vector_candidate_p): Check that TImode regs that
are SET_DEST or SET_SRC of an insn match/are single_def_chain_p.
gcc/testsuite/ChangeLog
PR target/106933
PR target/106959
* gcc.target/i386/pr106933-1.c: New test case.
* gcc.target/i386/pr106933-2.c: Likewise.
* gcc.target/i386/pr106959-1.c: Likewise.
* gcc.target/i386/pr106959-2.c: Likewise.
* gcc.target/i386/pr106959-3.c: Likewise.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92
2022-09-13 18:49 [Bug target/106933] New: [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) asolokha at gmx dot com
` (9 preceding siblings ...)
2022-12-23 9:52 ` cvs-commit at gcc dot gnu.org
@ 2022-12-24 17:16 ` roger at nextmovesoftware dot com
10 siblings, 0 replies; 12+ messages in thread
From: roger at nextmovesoftware dot com @ 2022-12-24 17:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
Roger Sayle <roger at nextmovesoftware dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #9 from Roger Sayle <roger at nextmovesoftware dot com> ---
This should now be fixed on mainline. Thanks HJ and Uros.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-12-24 17:16 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-13 18:49 [Bug target/106933] New: [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) asolokha at gmx dot com
2022-09-13 19:23 ` [Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92 marxin at gcc dot gnu.org
2022-09-14 6:25 ` rguenth at gcc dot gnu.org
2022-09-14 11:39 ` roger at nextmovesoftware dot com
2022-09-14 12:35 ` roger at nextmovesoftware dot com
2022-10-06 16:03 ` asolokha at gmx dot com
2022-10-06 17:18 ` hjl.tools at gmail dot com
2022-10-18 8:45 ` rguenth at gcc dot gnu.org
2022-10-21 18:53 ` hjl.tools at gmail dot com
2022-12-01 12:49 ` jakub at gcc dot gnu.org
2022-12-23 9:52 ` cvs-commit at gcc dot gnu.org
2022-12-24 17:16 ` roger at nextmovesoftware dot com
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).