Follow up on this thread. I don’t see any objection on this proposal. There was one suggestion from @preames about changing the semantics to be exactly the same as RISC-V’s vsetvli until there are more targets using it in the future.
I think in any case we should look at how llvm.experimental.get.vector.length is used and supported now. Here is a quick summary:
- RISC-V is actively using it
- AArch64 has (basic) codegen for it, but doesn’t seem to generate it anywhere
- VE supports scalable vector, but it doesn’t use this intrinsic nor does it really need it. Because to my best understandings, in VE, if the “AVL” – user provided vector length – exceeds maximal vector length, VE simply throws an exception. So there is little incentive to use it even in the future.
- As @ppenzin pointed out, WASM has a draft proposal for a similar thing. Except it returns the number of remaining elements instead.
Combining all the facts we’d seen here, I think either sticking to the current proposal or specializing it to RISC-V’s semantics are viable options going forward.
Personally I’m inclined to keep the current proposal, primarily because I don’t want it to be too RISC-V specific. I will send our a PR shortly for updating the LangRef.
Update: PR is here: [LangRef] Update the semantic of `experimental.get.vector.length` by mshockwave · Pull Request #104475 · llvm/llvm-project · GitHub