Use fixed-width integer type instead of long?

[riscv-non-isa]

Use fixed-width integer type instead of long?

[kito-cheng]

I saw there is similar request in several intrinsic design, including P-extension and B-extension, maybe we should add that into psabi?

[zakk0610]

FYI: this discussion was moved to riscv-non-isa/riscv-elf-psabi-doc#158.

[topperc]

We're working on upstreaming the rvv intrinsics to llvm/clang. I'm trying to figure out if this is an issue we should worry about for that.

I need to define builtins for vsetvl and all the intrinsics that take a vl operand. clang's system for specifying builtins mostly uses fixed types. There are currently a few special cases, for example saying a builtin needs a 64 bit type where will choose long or long long depending on which is really 64 bits. There's also a special case to say a builtin takes size_t. There isn't any target specific overrides into that code today so I don't have a way of saying a builtin takes an xlen integer and I'm not sure how to abstract it into target independent code. Maybe I can have it find the same type as attribute ((mode (word)))?

Another option might be to just say that vl is a 32-bit "unsigned" in the C interface? Greater than 4 billion element vectors seems like a lot.

[nick-knight]

My advice is the following:

1. Update the RVV Intrinsics spec to use uint_xlen_t, plus some explanation of what this means (see above). I.e., tell the user that the vl argument should be an XLEN-width unsigned integer, and it's up to them to correctly instantiate values of this type.

2. In the current LLVM implementation, just use unsigned long, which will do the right thing for all extant ABIs. We can repay this technical debt in the future: once the RISC-V C API adds support for uint_xlen_t --- which I'm confident will happen --- this will have to be added to LLVM.

[eopXD]

We have existing proposal in riscv-c-api-doc #14 that is still pending. I understand the fastest way here is to define the types in the RVV intrinsic header, but the formal completion should allow multiple extensions to use this defined type.

This issue will be held and resolved after v1.0 since it is depending on more consensus in the RISC-V community.