Should vcpop.m return type be size_t?

[HanKuanChen]

Current interface

unsigned long vcpop_m_b1 (vbool1_t op1, size_t vl);

However, the semantic of vcpop.m is

The vcpop.m instruction counts the number of mask elements of the active elements of the vector source mask register that have the value 1 and writes the result to a scalar x register.

That means the maximum value depends on VL. And VL related interface is

size_t vsetvl_e8mf8 (size_t avl);
size_t vsetvlmax_e8mf8 ();

So, should we change the interface to

size_t vcpop_m_b1 (vbool1_t op1, size_t vl);

[jan-wassenberg]

Sounds good to me.

[nick-knight]

I've always disagreed with using implementation-defined size_t for VL, and would prefer something like riscv-non-isa/riscv-c-api-doc#14 that more closely matches the architecture: VL is defined as an XLEN-bit CSR and its value is always exchanged through (XLEN-bit) X-registers.

My disagreement, however, is very mild: C99 requires size_t be at least 16 bits, and of course is XLEN bits in our standard ABIs.

I have a related complaint for vfirst.m. Currently we use long, which again is implementation defined but the C language guarantees it has sufficient range for our purposes, and also it is XLEN bits in our standard ABIs.

So I support the proposal here, and support maintaining the status quo for vfirst.m, but still think the XLEN-width types provide a better solution.