On Sat, 10 May 2025 09:42:16 PDT (-0700), jeffreya...@gmail.com wrote:
On 5/10/25 6:30 AM, Jiawei wrote:
This patch introduces support for RISC-V Profiles RV20 and RV22 [1],
enabling developers to utilize these profiles through the -march option.
[1] https://github.com/riscv/riscv-profiles/releases/tag/v1.0
Version log:
Using lowercase letters to present Profiles.
Using '_' as divsor between Profiles and other RISC-V extension.
Add descriptions in invoke.texi.
Checking if there exist '_' between Profiles and additional extensions.
Using std::string to avoid memory problems.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (struct riscv_profiles): New
struct.
(riscv_subset_list::parse_profiles): New parser.
(riscv_subset_list::parse_base_ext): Ditto.
* config/riscv/riscv-subset.h: New def.
* doc/invoke.texi: New option descriptions.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/arch-49.c: New test.
* gcc.target/riscv/arch-50.c: New test.
* gcc.target/riscv/arch-51.c: New test.
* gcc.target/riscv/arch-52.c: New test.
Both patches in this series are OK. Please install.
Looks like they did. I'm not trying to argue with that, but I was
talking to some distro people and this came up. So I figured I'd leave
a bit of a summary here in case anyone else goes down the same rabbit
hole:
Supporting these profile arguments really has nothing to do with whether
or not distros can target a profile. The profiles are just a short name
for a bunch of ISA extensions, vendors still self-certify their
implementations and can claim profile/extension compatibility without
actually implementing the behaviors defined by the specification.
We do our best to work around these sorts of issues is software land
(mostly handling the traps in the kernel), but it's really a losing
battle. At best we get something correct long after the systems ship,
usually with some disastrous impact on performance. I don't think
there's really a way to change that on the SW side of things, it's just
the natural end result of this weak stance on compatibility in RISC-V
land.
If users want to generate code that runs correctly and/or performance
well on a set of RISC-V systems, they need to go find the common ground
of what those systems actually implement (ie, not what the marketing
material says) and then go target those extensions. That's a bunch of
work for users, but it's just where we are right now.
When this came up a few years ago we decided not to put some sort of
"target all the hardware that shipped in 2022" type argument for GCC
because we didn't have a good enough idea of what distros are going to
want to target. That still seems reasonable to me, but with binary
distros in the pipeline it looks like we're going to be figuring that
out sooner rather than later.
Thanks again,
Jeff
