Use wider integers for shifts

[nick-knight]

I'm concerned about several intrinsics which input a "shift" amount as uint8_t. This only allows shifts up to 255, which fails to expose underlying functionality for larger SEW (and ELEN).

Particular examples are vsll_vx, vsr{a,l}_vx, vnsr{a,l}_vx, vssr{a,l}_vx, and vnclip{,u}_wx. I only skimmed quickly; perhaps there are more.

The vv/wv forms use an appropriate type-width --- one that increases with SEW --- for their (vector) op2, and I suggest matching that in the vx/wx forms.

(It's true that the vi forms are restricted to a 5-bit op2, but these forms aren't exposed in the intrinsics API.)

EDIT: on further thought, perhaps it's more appropriate to use uintXLEN_t (or whatever it's called).

[zakk0610]

Agree, spec already reserves SEW=1024 supported.

Unfortunately uintXLEN_t is still in the PR, riscv-non-isa/riscv-c-api-doc#14
Which type are you prefer to use? unsigned long?

[nick-knight]

I propose we just define uint_xlen_t in the usual way in the riscv_vector.h, and delete it when the C API PR is approved and added to compilers. Hopefully this can be done without breaking user code because riscv_vector.h is bundled with the toolchain.

I'm pretty sure the P-extension does the same thing in their intrinsics header file. I don't know about other extensions' intrinsics.

I'm not an expert on this kind of thing, happy to hear alternatives.

[kito-cheng]

I propose we just define uint_xlen_t in the usual way in the riscv_vector.h, and delete it when the C API PR is approved and added to compilers. Hopefully this can be done without breaking user code because riscv_vector.h is bundled with the toolchain.

That SGTM, I think intrinsic for B extension should need that too.

[zakk0610]

Before we have uint_xlen_t, could we use size_t type for shift amount ?

[nick-knight]

This was addressed by #72 , although I think this and related aspects of the API should be revisited once we have XLEN-width integer types to replace size_t, long, etc.