RFC: Explicit VL API as The Final Vector Intrinsic API Proposal

[riscv-non-isa]

RFC: Explicit VL API as The Final Vector Intrinsic API Proposal

[nick-knight]

I was formerly a strong proponent of the implicit-VL API, and a mild opponent of the explicit-VL API. I am now convinced that explicit-VL can provide better code generation, due to capabilities/limitations of current compilers. This is a practical argument, not a mathematical one, but that distinction is irrelevant to the performance programmer.

I am on board.

[rdolbeau]

Works for me (given previous discussion in e.g. #8 no surprise there ;-) ).

[kito-cheng]

Just to be sure: a function that wants to "set VL" and then restore the previous value would just vsetvl, pass the result to *_vl() ops, and the compiler takes care of restoring/setting other VL after returning?

In theory, you don't need to care about the VL register anymore if we only using explicit VL API, so yes, the compiler will handle that VL register restoring/setting, it's all compiler's responsibility now.

Also, is vse32_v_i32m4_vl(a, tmp); missing the last argument?

Updated, Thanks!

[kito-cheng]

Note: Corresponding PR will sent in next few days.

[jan-wassenberg]

@kito-cheng
Sounds good to me. This seems to match the direction taken by llvm-vp (adding VL and mask to IR ops). We have also seen some bugs caused by (manually) reordering intrinsics, which would not have happened if they were pure functions.

Just to be sure: a function that wants to "set VL" and then restore the previous value would just vsetvl, pass the result to *_vl() ops, and the compiler takes care of restoring/setting other VL after returning?

Also, is vse32_v_i32m4_vl(a, tmp); missing the last argument?

[kito-cheng]

Works for me (given previous discussion in e.g. #8 no surprise there ;-) ).

@rdolbeau Thanks your take a stand for this RFC!

[wuiw]

@kito-cheng, thanks for your sharing.

Same with @knightsifive, I was formerly a strong proponent of the implicit-VL API. However, this proposal convinces us. If possible, let this proposal being landing down asap.

[kito-cheng]

Here is the PR #64 for this RFC :)

[kito-cheng]

Corresponding changes are merged.