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 20D393857B93; Sat,  9 Sep 2023 08:24:33 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 20D393857B93
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1694247873;
	bh=k7my/I43nY/NNQIKjPnPxM81GUdeidjpMprJ5yRuCog=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=uu12Tb8Dha2D4TqPP00U2vFXURmfY4MjR30EVpFcmJO5e4XfFh2s5WBBzHO1sVE+j
	 w4w97A90zkAPikm16/jQGdX249iHRnMzHmh2ddXRaHcfphgKCc/3oZzqcTjXVgLQHM
	 PQLo8NscHO57zX6MiPLxoTSTd8e+zNfiSqCSRbrc=
From: "chenglulu at loongson dot cn" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/111334] [14 regression] ICE is reported during the
 combine pass optimization
Date: Sat, 09 Sep 2023 08:24:32 +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: chenglulu at loongson dot cn
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: <bug-111334-4-pDswv9P2qS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-111334-4@http.gcc.gnu.org/bugzilla/>
References: <bug-111334-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=3D111334

--- Comment #18 from chenglulu <chenglulu at loongson dot cn> ---
(In reply to Xi Ruoyao from comment #17)
> I think the proper description should be:
>=20
> diff --git a/gcc/config/loongarch/loongarch.md
> b/gcc/config/loongarch/loongarch.md
> index 75f641b38ee..000d17b0ba6 100644
> --- a/gcc/config/loongarch/loongarch.md
> +++ b/gcc/config/loongarch/loongarch.md
> @@ -64,6 +64,8 @@ (define_c_enum "unspec" [
>    UNSPEC_CRC
>    UNSPEC_CRCC
>=20=20
> +  UNSPEC_DIV_W_OPERAND
> +
>    UNSPEC_LOAD_FROM_GOT
>    UNSPEC_PCALAU12I
>    UNSPEC_ORI_L_LO12
> @@ -892,7 +894,7 @@ (define_expand "<optab><mode>3"
>      emit_insn (gen_rtx_SET (reg1, operands[1]));
>      emit_insn (gen_rtx_SET (reg2, operands[2]));
>=20=20
> -    emit_insn (gen_<optab>di3_fake (rd, reg1, reg2));
> +    emit_insn (gen_<optab>si3_extended (rd, reg1, reg2));
>      emit_insn (gen_rtx_SET (operands[0],
>  			    simplify_gen_subreg (SImode, rd, DImode, 0)));
>      DONE;
> @@ -915,11 +917,14 @@ (define_insn "*<optab><mode>3"
>  	(const_string "yes")
>  	(const_string "no")))])
>=20=20
> -(define_insn "<optab>di3_fake"
> +(define_insn "<optab>si3_extended"
>    [(set (match_operand:DI 0 "register_operand" "=3Dr,&r,&r")
>  	(sign_extend:DI
> -	  (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> -		      (match_operand:DI 2 "register_operand" "r,r,r"))))]
> +	  (any_div:SI
> +	    (unspec:SI [(match_operand:DI 1 "register_operand" "r,r,0")]
> +		       UNSPEC_DIV_W_OPERAND)
> +	    (unspec:SI [(match_operand:DI 2 "register_operand" "r,r,r")]
> +		       UNSPEC_DIV_W_OPERAND))))]
>    ""
>  {
>    return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
>=20
> i. e. we define "UNSPEC_DIV_W_OPERAND" as a "machine-specific operation":=
 if
> the input is a sign-extended 32-bit value, the operation extracts the low
> 32-bit; otherwise, it produces random junks.
>=20
> Note that the behavior actually depends on the values of operand[1] and
> operands[2], not the result of operand[1] / operand[2].  So we should put
> unspec inside any_div, not outside.
>=20
> (I've not included the TARGET_64BIT change here, it should be done anyway=
.)
>=20
> BTW is LA664 improved to handle non-properly-extended inputs with div.w?

This problem has been fixed on LA664=EF=BC=8E
I don't quite understand why this operation is still needed in !TARGET_64BI=
T?=