From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 9BD483861001; Fri, 26 Apr 2024 13:51:02 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9BD483861001
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1714139462;
	bh=HTSqIKxiW3wafBTMae0aSpw34wkk07hESmQTnPWb52E=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=tIiPOO6ywflmUZbmeLUJNIc53YkHMNh3foggZ4NRV0EtVthYWw1myRRC6tsFDu8ey
	 /Tt6P6pwGQGuso7QNvKuGqBNr2b7jjijTWjo2BWJtvnJ7n4ytxqUeRwGCTlinleJz0
	 E3SG6+noQgKX4XUsfiTh1kP0oBwhJ/QL2sPJNGls=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/114801] [14/15 Regression] arm: ICE in
 find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
Date: Fri, 26 Apr 2024 13:51:02 +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: jakub at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: clyon at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-114801-4-SkEYIc5ia0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114801-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114801-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114801

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Guess the primary question is why there is the gen_lowpart call at all.
Is it that normally the mode of x is already right due to the prototypes of=
 the
builtins, with the exception that gcc likes to promote QImode/HImode argume=
nts
of calls to SImode, so is the intent in that case to just narrow down SImode
back to HImode (seems VALID_MVE_PRED_MODE is only true for HImode from scal=
ar
MODE_INT modes)?

If so, best would be to limit the call to just that case.
So (completely untested):
--- gcc/config/arm/arm-mve-builtins.cc.jj       2024-03-19 09:51:05.2036311=
94
+0100
+++ gcc/config/arm/arm-mve-builtins.cc  2024-04-26 15:49:55.380344060 +0200
@@ -2100,7 +2100,12 @@ function_expander::add_input_operand (in
       mode =3D GET_MODE (x);
     }
   else if (VALID_MVE_PRED_MODE (mode))
-    x =3D gen_lowpart (mode, x);
+    {
+      if (mode =3D=3D HImode && GET_MODE (x) !=3D HImode)
+       /* GCC promotes QI/HImode arguments to int, undo that
+          here.  */
+       x =3D lowpart_subreg (mode, x, SImode);
+    }

   m_ops.safe_grow (m_ops.length () + 1, true);
   create_input_operand (&m_ops.last (), x, mode);

I'd hope if the argument is a vector mode x already has that mode...=