From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C7EDA3858CDB; Fri, 28 Apr 2023 14:41:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C7EDA3858CDB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1682692916; bh=ohlvdyqdWo/Cjc3Z6x345SjdzTOPJ0Qon8jCL74eDYY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mHKPjXVtkshqGkw7MTMJoETZnb5VfImWY/JNfBYCdLMDux+E5kIlUA/zsPhDemvKI Fd1VqqQ879eCy7m5/olBZh58p99RmQIb5JcmZ7esgop1WAcX7m9p6zWoCSd0Bo7rYu vV8aS6BX15su+B2Gw8FAHRJBOMX7Vu8jSivwwq7o= From: "ktkachov at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/109636] [14 Regression] ICE: in paradoxical_subreg_p, at rtl.h:3205 with -O -mcpu=a64fx Date: Fri, 28 Apr 2023 14:41:56 +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: 14.0 X-Bugzilla-Keywords: ice-on-valid-code, needs-bisection X-Bugzilla-Severity: normal X-Bugzilla-Who: ktkachov at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: ktkachov at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.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=3D109636 --- Comment #7 from ktkachov at gcc dot gnu.org --- (In reply to rsandifo@gcc.gnu.org from comment #6) > Ugh. I guess we've got no option but to force the original > subreg into a fresh register, but that's going to pessimise > cases where arithmetic is done on tuple types. >=20 > Perhaps we should just expose the SVE operation as a native > V2DI one. Handling predicated ops would be a bit more challenging > though. I did try a copy_to_mode_reg to a fresh V2DI register for non-REG_P argumen= ts and that did progress, but (surprisingly?) still ICEd during fwprop: during RTL pass: fwprop1 mulice.c: In function 'foom': mulice.c:17:1: internal compiler error: in paradoxical_subreg_p, at rtl.h:3= 205 17 | } | ^ 0xe903b9 paradoxical_subreg_p(machine_mode, machine_mode) $SRC/gcc/rtl.h:3205 0xe903b9 simplify_context::simplify_subreg(machine_mode, rtx_def*, machine_mode, poly_int<2u, unsigned long>) $SRC/gcc/simplify-rtx.cc:7533 0xe1b5f7 insn_propagation::apply_to_rvalue_1(rtx_def**) $SRC/gcc/recog.cc:1176 0xe1b3d8 insn_propagation::apply_to_rvalue_1(rtx_def**) $SRC/gcc/recog.cc:1118 0xe1b7b7 insn_propagation::apply_to_rvalue_1(rtx_def**) $SRC/gcc/recog.cc:1254 0xe1babf insn_propagation::apply_to_pattern_1(rtx_def**) $SRC/gcc/recog.cc:1361 0xe1bae4 insn_propagation::apply_to_pattern(rtx_def**) $SRC/gcc/recog.cc:1383 0x1c22e5b try_fwprop_subst_pattern $SRC/gcc/fwprop.cc:454 0x1c22e5b try_fwprop_subst $SRC/gcc/fwprop.cc:627 0x1c239a9 forward_propagate_and_simplify $SRC/gcc/fwprop.cc:823 0x1c239a9 forward_propagate_into $SRC/gcc/fwprop.cc:886 0x1c23bc1 fwprop_insn $SRC/gcc/fwprop.cc:943 0x1c23d98 fwprop $SRC/gcc/fwprop.cc:995 0x1c240e1 execute $SRC/gcc/fwprop.cc:1033 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See for instructions. fwprop ended up creating: (mult:VNx2DI (subreg:VNx2DI (reg/v:V2DI 95 [ v ]) 0) (subreg:VNx2DI (subreg:V2DI (reg/v:OI 97 [ w ]) 16) 0)) and something blew up anyway, so it seems the RTL passes *really* don't like these kind of subregs ;) I'll look into expressing these ops as native V2DI patterns. I guess for the unpredicated SVE2 mul that's easy, but for the predicated forms perhaps we = can have them consume a predicate register, generated at expand time, similar to the aarch64-sve.md expanders. Not super-pretty but maybe it'll be enough=