[libre-riscv-dev] [isa-dev] Re: SV / RVV, marking a register as VL.

[lkcl]

so, i appreciate i might appear to be "overdoing it" on the 
functions-thing.  think it through, from the perspective of 
distro-distriibuted packages, which i do appreciate is not exactly very 
common at the moment.

* standard packages from e.g. debian or fedora are RV64GC Unix-platform 
compliant
* hardware has a special mode (SVMODE) which provides vectorisation, where 
the function-call convention is changed to "leave it on"
* that means that every debian/fedora-packaged library used by the new 
hardware mode needs to be multilib compiled to understand this new 
convention.
* that in turn means that every single package needs to have a patch 
submitted to the packaging (debian has over 30,000 packages)
* appliications will still not be safe to run until *all* its dependent 
libraries have had the new SVMODE multilib recompile.

you see where that's going?  it'd be literally years before the entire 
debian/fedora (etc.) distro suite was able to fully take advantage of the 
new hardware, across the board.

or...

you could have a convention where each function is "self-contained 
responsible" for clean-up.  that means that any function becomes 
vector-accelerated *immediately*, with no knock-on recompilation 
consequences required.

users will put in individual requests for the new hardware-accelerated 
support (and/or help out in doing that by actually submitting packaging 
patches), on a *per-package* basis, and get immediate results.

if that convention's realistically and pragmatically accepted / acceptable, 
then the next phase is to actually optimise the hardware based around the 
convention and on a sensible desire to reduce code size.

so it's not that skipping SVMODEs-cleanup isn't a good way to save on 
instruction count: it is... it's just that such a dramatic change to 
standard function-call conventions has undesirable knock-on consequences 
when it comes to UNIX Platform software distribution / libraries.

interestingly, the exact same thing is going to apply for RVV when it's in 
common usage.  with RVV it will also not be safe to assume a convention 
that RVV vector setup has been left in a useable / useful state, except if 
a tree of functions are used statically within the same source code file.

l.