I would like to emphasize Zalman Stern's point about trading off hardware
economy for dynamic software optimization, in the context of a larger
comment about optimizing compiled code for RISC-V. The specification of RVV
is designed very well to work well across a variety of hardware
implementations without requiring different code, but IMO one of the great
truths of system design is that "compilation beats interpretation," and in
this context, execution-time parameterization as defined for RVV is a form
of interpretation that, like many kinds of interpretation, trades space and
time overhead for convenience.

For it to be most effective, the representation *from* which run-time code
is generated must be sufficiently high-level: the higher the level, the
greater the opportunities to tailor the code to the hardware. Not having
experience with vector-amenable computation, I can't say anything more
specific, other than to note the historical tug of war between, on the one
hand, compilers that recognize vectorizable constructs in low-level
languages like C, and on the other, very high-level languages like APL or
Halide.

The relevance to the present discussion is that RTCG may require detailed
configuration discovery ABI/API that goes beyond the ABI for functional
code. I hope the work of the relevant group(s) will take this into
consideration.

--

L Peter Deutsch :: Aladdin Enterprises :: Healdsburg, CA & Burnaby, BC