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 3884C3858D35; Mon, 29 Apr 2024 14:11:55 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3884C3858D35
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1714399915;
	bh=O61x4xZDeyIRgjbbl674lNM3MqNQQhLLl2OcdMIiBeY=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=cEqvur5hdR20cxOY4119iwDa4XUC7/QkjNTxSqINe516XeSlpl5Zw9qAomqBiEugc
	 ugmrkTVDoMesNdM+NKwy7ZCzs/dvOCptkenbfaFLDq7vYsV+UcHrjqhq3gfxlaKPiY
	 Y7NUgCXBIK+g0Dq2ChWP6oKwkOSsavB3dIQfkNxQ=
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: Mon, 29 Apr 2024 14:11:54 +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-6JNMXjmWJ3@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 #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Christophe Lyon from comment #22)
> Sure, that's what I'm worried about.
>=20
> So we can:
> - leave this as-is for gcc-14 (known bug)
>=20
> - commit what we discussed in #c15 #c16, (with an improved testcase as you
> mentioned on the list,) thus at least temporarily forcing canonicalization
> (preventing users from using 'weird' values)
>=20
> - possibly revisit this for gcc-15 by handling predicates differently

This primarily needs to be ARM maintainer decision.

Anyway, if the predicate is really always a byte predicate, then perhaps be=
st
representation would be to always use V16BImode for it and model it in the =
RTL
patterns as VEC_SELECT of a subreg of the actual operation to V16QImode (and
then subreg back).
That might accurately model what the hw does.
Or some UNSPECs with just HImode predicate and then hide what actually happ=
ens.=