https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111020
--- 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. > > 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. > > 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 instructions > 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 explosion 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.
