From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9A5263858024; Wed, 14 Sep 2022 12:35:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9A5263858024 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1663158930; bh=51yihB45yL9PCgo/GOJvY7l7iQKW6A11iHtvMBdIOck=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fR+dqHrFuahm/B2gEQp66JIb/Ik7ChQ5Ubq2rzt9/WIby/wHUoewUJ+c5VJrARvuD 04+eaJN4w8N8tKTBHMG5NZPu9FIvmwrAWwCdvvx0GoRECG3iYccE1SmjNQL5AsROjI sEgXcv8J2M7D/Zsw3fzOBboPMoMcY4ZVGi2gJbvs= From: "roger at nextmovesoftware dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92 Date: Wed, 14 Sep 2022 12:35:30 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: roger at nextmovesoftware dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106933 --- Comment #3 from Roger Sayle --- 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 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]=3Dr82:TI REG_DEAD r91:DI Total gain: 5 Converting chain #7... deferring rescan insn with uid =3D 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=3Dcmp(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 la= ck on initialization makes them look independent.=