On Thu, 05 Sep 2024 07:27:57 PDT (-0700), nat...@acm.org wrote:
Hi,
looking at the RISCV code, it seems that there are several vendor-specific files
in config/riscv. For instance sifive-7.md and xiangshan.md. It seems these are
unconditionally included for all riscv targets. I guess then one doesn't end up
with some combinatorial explosion of possible riscv compilers. But it doesn't
seem scalable, given the one of the points of riscv is to add your own magic
pixie dust.
Ya, this has always been a point of tension in RISC-V land: the main
argument for using RISC-V is that vendors can go do whatever they want,
but then you end up with a bunch of fragmentation and a very clunky
software stack. We've got basically the same problem all over the
place, and it's not even limited to just vendor stuff -- even if you
just stick to the standard extensions, we've now got way more RISC-V ISA
flavors than there are people on earth. It's just not viable to make
that all fit together in any sort of sane way, it's too big of a number
for anyone.
So far we've tried really hard to avoid forks on the software side of
things -- either proper hard forks (ie, just making a different config/
directory and it another ISA) or soft forks (ie, scattering a bunch of
#ifdefs around and ending up with single-vendor builds). That has led
to a ton of complexity in software land, but I still think it's a good
goal as we've seen how much of a mess can come from going the other way
from other targets.
That said, I do get that it's painful just on a day-to-day level. It is
for everyone, I just don't really think there's a way around it -- like
you said above, it's the design of the ISA.
In my case, I have a port that also has a bunch of vendor-specific passes, which
have unfortunately been placed in the main gcc directory. They directly rely on
an API added to config/riscv. IMHO placing them in a vendor subdirectory of
config/riscv would seem cleaner. Then have config glue to include them in the
build under something like a --with-riscv-$vendor-extensions configure flag
Whether this port gets considered for upstreaming is unknown.
So I think there's generally this "if it's not going upstream it doesn't
count" type argument in open source land. It always feels a bit
antagonistic, though.
IMO these "maybe it's going upstream" things are always the tricky bit:
if you know it's not going upstream you can just hack out the bits you
don't care about, and if you know it's going upstream then you'll
eventually need to play nice so might as well keep them. It's just kind
of hard to argue to do the extra work there when you don't know if it's
going to be useful.
Anyway, I guess I'm suggesting that, for new code:
1) vendor-specific files get put in a config/riscv/$vendor subdirectory
Is that so different than just having them in different files?
That's sort of how we split stuff out now, though there's a lot mixed
together in the generic files. At a certain point all thus stuff ends
up somewhat coupled anyway, as you can't just independently write stuff
in MD files without understanding the rest of the port (and some amount
of the rest of the vendors' behavior).
The constant gen stuff is a perfect example: there's just a bunch of "if
you've got this extension flavor, then it's cheap to make those
constants". We could throw some code at the problem to let that stuff
live in its own files, but I'm not sure that's a net win in terms of
complexity.
There's also some stuff that's vendor-specific-ish -- I'm thinking of
stuff like the condops, for example, where we've got multiple vendor
extensions that basically do the same thing and then a standard
extension that does it slightly differently. I'd bet we end up in that
situation fairly often, at least on the supervisor side of things that's
happened a few times in supervisor land.
2) configure-time options determine whether a specific vendor's bits are
included in the build.
IMO as long as we can turn on all the vendor stuff in the same build
then I'm fine with something like that. I just don't know if it'd
actually help, as there's enough cases with coupling that it kind of
feels like splitting stuff out is going to be more work than we save.
I'd really strongly be opposed to defaulting to per-vendor builds,
though. I think we'd pretty quickly end up with a tangled mess of
conflicting code that's going to make things hard to maintain.
$vendor names can be those used in the X$vendor$suffix ISA extension scheme
thoughts?
nathan
