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 22FA23858C62; Tue, 15 Aug 2023 02:37:36 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 22FA23858C62
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1692067056;
	bh=cmT0/pqspZ/+0N+I6egZnJKAoSQhtrq4X7Ttgy2Wu9M=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=plZ06jxmiHqoBMvChYjRbZzYwLsnp47LX8pYdjLXSSo5RIEtXU9XZlNJFb3NLAlN0
	 8k4OfCyR/cLdrd6FQK44UFq9WrhSMmkEqDe7RSdohjbSihiTY/rBYOqUm/TGASqEtJ
	 Byjta3fEUeHAwDWwv4bwJMG+SgoT/AJvn1i2wtow=
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/111020] RFE: RISC-V: ability to cherry-pick additional
 instructions
Date: Tue, 15 Aug 2023 02:37:35 +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: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-111020-4-kI2wFY0Zew@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-111020-4@http.gcc.gnu.org/bugzilla/>
References: <bug-111020-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=3D111020

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to H. Peter Anvin from comment #2)
> Named subsets are, inherently, designed to make sense toward mass-produced
> products where the hardware and software are designed (mostly)
> independently. However, what I mean with "very deep embedded use" is
> hardware and software being co-designed.
>=20
> The RISC-V ISA policy is that those are considered vendor-specific subsets
> and are to be given an X* name; however, gcc obviously needs to be able to
> understand the meaning of this X* name. At this point there is no way to =
do
> without changing the source code in nontrivial ways.
>=20
> Regardless of if it is done in source code or at runtime, by implementing=
 a
> fine-grained, preferably table-driven, approach to subsets in gcc then it
> would be very simple for a hardware implementor to define their custom
> X-subsets without a lot of surgery to the code, *and* it makes it possible
> to take it one step further and allowing custom (or newly defined! - there
> have been multiple instances already of new subsets of existing instructi=
ons
> defined a posteori) instruction subsets to be defined in a configuration
> file.

I am 100% disagree here. Because if you do this there would be a huge explo=
sion
of what is and is not considered a subset. THIS is why it should be defined=
 at
the ISA level instead. Why just CTZ for ZBB what next just bseti or bexti of
ZBS?

defining the specific set during your development is different from a
production compiler really. GCC should aim for production compiler quality =
even
for highly embedded targets.=