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 AD3D53858C42; Mon, 29 Apr 2024 15:52:26 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AD3D53858C42
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1714405946;
	bh=jbdQeRSBkvmzna5C3zkPLKsflowwX7nxnNlEn76CMwY=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=aqAjbBuS7WL1LGRbRZ1jf+LRPaQfXMi7P1IHyfJiEBdG92Qeu9mMnKEkRpLKKR0Od
	 tmO0We/NIkHmFjEgQwd/SZQ2gNvFBBjiKm/IdobZXlFa+L+xGk+ClmuR00VW2FU0lw
	 2CEwQWw1WgwrrF2a+gOMXDNVR04j8003twZvvCEI=
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 15:52:26 +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-h7NmTj872K@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 #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #24)
> Another short term (14.1 only) possibility would be to force_reg a CONST_=
INT
> operand into a register if it didn't have all bits the same (and hope
> combine or whatever else won't simplify it again), i.e.
>    else if (VALID_MVE_PRED_MODE (mode))
>      {
>        if (CONST_INT_P (x) && (mode =3D=3D V8BImode || mode =3D=3D V4BImo=
de))
>          {
>            /* In V8BI or V4BI each element has 2 or 4 bits, if those
>               bits aren't all the same, gen_lowpart might ICE.  */
>            unsigned HOST_WIDE_INT xi =3D UINTVAL (xi);

UINTVAL (x) above.

>            if ((xi & 0x5555) !=3D ((xi >> 1) & 0x5555)
>                || (mode =3D=3D V4BImode
>                    && (xi & 0x3333) !=3D ((xi >> 2) & 0x3333)))
>              x =3D force_reg (HImode, x);
>          }
>        else if (SUBREG_P (x))
>          /* gen_lowpart on a SUBREG can ICE.  */
>          x =3D force_reg (GET_MODE (x), x);
>        x =3D gen_lowpart (mode, x);
>      }
> If that fixes just the ICE during expansion but ICEs during fwprop, combi=
ne
> etc.,
> then you might try (temporarily) harder and hide the constant from the
> optimizers,
> e.g. instead of using force_reg emit some (set (reg:HI) (unspec:HI
> (const_int ...) UNSPEC_MVE_PRED)) insn that expands like (set (reg:HI)
> (const_int ...)) but the
> optimizers don't know that.

Indeed, it ICEs e.g. during CSE.
Though, that also means it is just about luck, if something isn't a CONST_I=
NT
at expansion time but simplified into CONST_INT later, it can ICE as well.=