Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Would it be possible to list RISC-V intrinsics in ways other than using the C programming language? #107

Closed
luojia65 opened this issue Aug 2, 2021 · 5 comments

Comments

@luojia65
Copy link

luojia65 commented Aug 2, 2021

Hello! I recently noticed how intrinsics are used in high performance CPU-bound applications. Using intrinsic functions in other architectures can allow us to use SIMD or vector conveniently in programming languages. RISC-V's V extension is more flexible, if it is written only in C programming language, it is convenient, but also includes a relevantly large amount of functions.

If we pick a language to declare intrinsic functions for one architecture, we may assume this language should be simple, expressive and relevantly widely used. Or in other words:

  • closer to hardware
  • may not have very high cost abstraction
  • abundant in language semantics
  • have an actual use or have users in production

For another replacement we choose Rust, for it's a systems programming language, at most time low cost in abstraction, widely used (of course, support RISC-V) and have lots of stable language features like const generics. We may assume ways in Rust to describe RISC-V intrinsic functions, to provide an alternative when C programming language is not applicable.

What other concerns and issues would we met if RISC-V's V intrinsic docs is provided along with other programming languages? Thank you!

@lu-zero
Copy link

lu-zero commented Sep 11, 2021

rust-lang/stdarch#913 is the issue currently open to track the integration.

Would be nice if there is a way to automatically generate the bindings.

@zakk0610
Copy link
Collaborator

LLVM uses RISCVVEmitter.cpp to read riscv_vector.td and generate the bindings from C intrinsic to clang builtin (riscv_vector.h)

ex.

#define vaadd_vv_i16m1(op0,op1,op2) __builtin_rvv_vaadd_vv_i16m1((vint16m1_t)(op0), (vint16m1_t)(op1), (size_t)(op2))

maybe it's a good way to use it generate the bindings.

@lu-zero
Copy link

lu-zero commented Sep 21, 2021

It is quite large and quite deep inside llvm, would be great to look if the python generator that is mentioned in few places could be repurposed for that.

@luojia65
Copy link
Author

luojia65 commented Dec 18, 2021

I have a new way to implement intrinsics in languages that supports template or generics. I wrote an example here: https://github.com/luojia65/rust-rvv-intrinsics/blob/main/examples/vadd.rs .

Specially:

let vl = vsetvl::<vint8mf8_t>(n);
let vs1 = vlv(a_ptr, vl);
let vs2 = vlv(b_ptr, vl);
let vd = vaddvv(vs1, vs2, vl);
vsv(c_ptr, vd, vl);

This way of implementing intrinsics significantly reduce amount of functions (less code size, build faster), get rid of always having to define the type of intermediate variables, and checks error more conveniently. It's useful to write generic codes where original C code only define them as different functions.

For checking error on build time, if I wrote wrong type for vector operations (vint16mf4_t, but correct type should be vint8mf?_t to add 8-bit vectors), it will raise error:

图片

(In this situation if adding different vector is needed, it should use vector cast functions)

@eopXD
Copy link
Collaborator

eopXD commented Aug 2, 2022

We will be releasing script to generate the intrinsic function for current C intrinsic API-s in the v1.0 release.

This request is duplicate to #105 asking for rvv_intrinsic_gen.py. Closing this one and let the former be the placeholder for this request.

@eopXD eopXD closed this as completed Aug 2, 2022
@eopXD eopXD added the Duplicate label Aug 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants