On 9/5/24 8:27 AM, Nathan Sidwell 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.
In general separating pipeline models is easy (and I think that's mostly
what you're seeing with the core specific md files).
When a core has custom extensions that don't overlap well with existing
ratified extensions, those can be split out pretty easily too.
Where things get nasty is vendor specific extensions that map closely to
ratified extensions. For example, there's parts out there with
zicond-like extensions or Zb*-like extensions. Those are tough to
figure out the best way forward.
And sometimes core specific extensions require changes into the common
risc-v code.
So it may seem like putting vendor stuff into a subdir/file makes sense,
but it's probably not as easy as you might think in practice.
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.
Anyway, I guess I'm suggesting that, for new code:
1) vendor-specific files get put in a config/riscv/$vendor subdirectory
2) configure-time options determine whether a specific vendor's bits are
included in the build.
#1 seems quite reasonable.
#2 could well be a long term maintenance problem. Not sure. We're
actually struggling a bit with this question for the core-v bit extensions.
jeff
ps. As much as folks think vendor extensions are a secret sauce for
risc-v adoption, I'm far from convinced it's a good idea...
