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 586953858D1E; Fri,  8 Sep 2023 07:03:28 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 586953858D1E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1694156608;
	bh=ceQRk7NEXrtXx3OvI11cv/PIEpnupKSMHo42wcmeaps=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=BhB5WTeVzJKIO25l9qtOBQqZkaa3oLtTvOaMm2qY0kovE6NSgz+NlEwK39G47+Kbc
	 5gkE0MUMLElPKeswPNtbFTclLlBEY50htDuYy4ggRnJTMhherKaefujyc6xftXn0NB
	 kK/KHrDjYy3NNZk4NPjJQdcLf/h7hS4BPN+HP99U=
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: Fri, 08 Sep 2023 07:03:28 +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-WJoJZ9GKdR@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 #13 from chenglulu <chenglulu at loongson dot cn> ---
(In reply to Xi Ruoyao from comment #12)
> (In reply to chenglulu from comment #11)
> > (In reply to Xi Ruoyao from comment #10)
> > > (In reply to Xi Ruoyao from comment #9)
> > >=20
> > > >  (define_insn "<optab>di3_fake"
> > > >    [(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"))))]
> > > > -  ""
> > > > +	(if_then_else
> > > > +	  (and (eq (match_operand:DI 1 "register_operand" "r,r,0")
> > > > +		   (sign_extend:DI (subreg:SI (match_dup 1) 0)))
> > > > +	       (eq (match_operand:DI 2 "register_operand" "r,r,r")
> > > > +		   (sign_extend:DI (subreg:SI (match_dup 2) 0))))
> > > > +	  (sign_extend:DI
> > > > +	    (any_div:SI (subreg:SI (match_dup 1) 0)
> > > > +			(subreg:SI (match_dup 2) 0)))
> > > > +	  (unspec:DI [(const_int 0)] UNSPEC_BAD_DIVW)))]
> > >=20
> > > With this the compiler will still believe all bad {div,mod}.w{,u}
> >=20
> > I think this is already defined as UNSPEC. Isn=E2=80=99t the simpler th=
e logic, the
> > better?
>=20
> Yes, I think we should just use 4 different UNSPEC_ values and the simple
> version.  But I've not find a way to use 4 different UNSPEC_ values in the
> RTL template except duplicating everything 4 times...

I still have a question that I don't quite understand, that is, why that the
four generated strings are equivalent when using an UNSPEC name? My template
names are different, and they will not be automatically matched during
optimization.???=