From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 937A13858C52; Mon, 22 May 2023 13:15:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 937A13858C52 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1684761349; bh=Nd6Fza5m1Czza9HWCyS8qFXEu1eO4D7F5eqpCaGwygM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=vki3ikWjKq4NklJPPmjw9Hdyj+lqFHMJKHqhxZNFt+Lbwr2Bj8PUfNNrtsjKSnnB3 JTZbmiyvonRA/R51MfnQxcbt//D63rYzQYf9Luvc+T5fm+N8z71DK/ISWKc/+tOsc4 AxmPP5UTtn2v0ZbJSItGHQmGCmlgpIbwt+GDD9mo= From: "ktkachov at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/109855] [14 Regression] ICE: in curr_insn_transform, at lra-constraints.cc:4231 unable to generate reloads for {aarch64_mlav4hi_vec_concatz_le} at -O1 Date: Mon, 22 May 2023 13:15:49 +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 X-Bugzilla-Severity: normal X-Bugzilla-Who: ktkachov at gcc dot gnu.org 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: 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=3D109855 --- Comment #5 from ktkachov at gcc dot gnu.org --- (In reply to rsandifo@gcc.gnu.org from comment #4) > I guess the problem is that the define_subst output template has: >=20 > (match_operand: 0) >=20 > which creates a new operand 0 with an empty predicate and constraint, > as opposed to a (match_dup 0), which would be substituted with the > original operand 0. Unfortunately >=20 > (match_dup: 0) >=20 > doesn't work as a way of inserting the original destination with > a different mode, since the : is ignored. Perhaps we should > =E2=80=9Cfix=E2=80=9D that. Alternatively: >=20 > (match_operand: 0 "register_operand" "=3Dw") >=20 > should work, but probably locks us into using patterns that have one > alternative only. I think this approach is the most promising and probably okay for the vast majority of cases we want to handle with these substs.=