From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E68E53857400; Fri, 15 Jul 2022 14:47:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E68E53857400 From: "roger at nextmovesoftware dot com" To: gcc-bugs@gcc.gnu.org Subject: [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 Date: Fri, 15 Jul 2022 14:47:28 +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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2022 14:47:29 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106303 --- Comment #2 from Roger Sayle --- Grr... This problem is at (currently just beyond) the limits of my abilitie= s.=20 The TImode STV pass uses data flow to split conversion opportunities up into chains, effectively performing live range splitting, as some of uses/defs o= f a pseudo register may be in one chain, and other (independent) uses/defs of t= hat pseudo in another chain. In the case reported in the PR, this results in s= ome 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 mapp= ing or unsharing... (or??). I'll continue investigating, but if anyone can see/knows the correct way to= fix this, please do let me know.=