[libre-riscv-dev] [isa-dev] Re: SV / RVV, marking a register as VL.
luke.leighton at gmail.com
Tue Sep 3 06:23:19 BST 2019
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
* 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
* 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.
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
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.
More information about the libre-riscv-dev