Giter Site home page Giter Site logo

Comments (6)

nick-knight avatar nick-knight commented on August 17, 2024 1

My opinion is that our first intrinsics effort should match the assembly language instruction names as closely as possible. Users are free to rename them as they see fit using (e.g.) preprocessor macros, and as time goes on we might decide to standardize these "aliases".

from rvv-intrinsic-doc.

rdolbeau avatar rdolbeau commented on August 17, 2024 1

@knightsifive Regarding the comments in https://github.com/sifive/rvv-intrinsic-doc/issues/7#issuecomment-614420632 and https://github.com/sifive/rvv-intrinsic-doc/issues/8#issuecomment-615358742...

I don't think it's a good idea to let the users do some workarounds to make the intrinsics more usable. This will generate (bad) legacy and causes trouble down the line. I think it's best to specify everything that is going to be done eventually, even if it's much later on due to manpower availability or other constraints (e.g. unspecified vector calling convention/ABI will prevent d) below). You want the users to know the level of support they will have from the tools (and maybe contribute some work rather than do it just for themselves ;-) ).

In my mind, there's four categories of 'intrinsics' that are eventually needed, and whose namespaces should be compatible:

a) The '1-to-1' intrinsics. Those will generate a known, single assembly instruction (unless perhaps overriden by a compiler option saying 'you can optimize some stuff away'). They are effectively equivalent to a single-instruction volatile asm statement (the compiler option merely take away the 'volatile' part) but with a more restrictive typing system (i.e. vint32m1_t vs vint64m1_t instead of a single 'vector' inline ASM constraint).

b) The 'basic support' intrinsics. Those makes the writing of intrinsics somewhat easier by removing the need to over-specify things. They include zero- or undefined-generation intrinsics, abstract version of some instructions (e.g. FMA but without specifying which register is overwritten) reinterpret (zero instruction, naturally), missing cases that are trivially generated (i.e. comparisons that aren't in hardware because they are trivially emulated with those actually available) ... They should usually generate up to one instruction (e.g. undefined-generation is likely to be zero instruction, comparisons will be one).

c) the 'helper/orthogonalization/compatibility' intrinsics. Those are meant to ease code writing/porting by adding 'missing' features that are reasonably easy to emulate, and compatibility between (unavailable) extensions. They generate a small number of instructions. You'd find the 64-bits vslide1up in RV32 (a couple of instructions), emulation of extensions disabled at compile time (i.e. allowing to generate replacement code for Zvlsseg '1-to-1' intrinsics such as a pair of strided load), etc. They allow to have a single codebase compile and work relatively painlessly across implementations (even though the generated binary might be more specific, such as in the Zvlsseg case).

d) the 'heavy duty' not-quite-intrinsics. Things that would be useful in a vectorization context, but are too heavy-duty to be called intrinsics, such as calling the vectorized version of libm, etc. Will require a proper vector calling convention/ABI, as many will be 'true' functions and not intrinsics. This may include a 'porting layer' that offers an easy way to move from other SIMD ISAs, but warning the user it may not be very efficient (e.g. the vi32.h and vi64.h files you can find in my Chacha20 code, which allows some data-manipulation SVE code to be ported straightforwardly, if not efficiently due to the heavy reliance on vrgather).

All those should be specified early, even if most implementations are #error "unimplemented", to tell the user what programming complexity to expect from V.

from rvv-intrinsic-doc.

zakk0610 avatar zakk0610 commented on August 17, 2024

based on current SiFive proposal, the function name would changed from

vint16m2_t vwadd_vs_i16m2 (vint8m1_t op1, int8_t op2);
vuint16m2_t vwadd_vs_u16m2 (vuint8m1_t op1, uint8_t op2);
vfloat32m2_t vwadd_vs_f32m2 (vfloat16m1_t op1, float16_t op2);

to

vint16m2_t vwadd_vx_i16m2 (vint8m1_t op1, int8_t op2);
vuint16m2_t vwaddu_vx_u16m2 (vuint8m1_t op1, uint8_t op2);
vfloat32m2_t vfwadd_vf_f32m2 (vfloat16m1_t op1, float16_t op2);

from rvv-intrinsic-doc.

zakk0610 avatar zakk0610 commented on August 17, 2024

There are also some operations don't care signed/unsigned, so its intrinsic function name would look likes

vint32m1_t vadd_vv_i32m1 (vint32m1_t op1, vint32m1_t op2);
vint32m1_t vadd_vv_u32m1 (vuint32m1_t op1, vuint32m1_t op2);

maybe consistency is important thing but we would break it due to inconsistency asm op name.

from rvv-intrinsic-doc.

Hsiangkai avatar Hsiangkai commented on August 17, 2024

I provide a document for general naming rules and exceptional naming rules.
https://github.com/sifive/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md
We could discuss the naming rules based on this primitive version.

from rvv-intrinsic-doc.

Hsiangkai avatar Hsiangkai commented on August 17, 2024

I provide 1-to-1 intrinsics, utility functions, and semantic intrinsics in the RFC document.
I also add naming guideline and exceptional cases for these intrinsics.
https://github.com/sifive/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md

from rvv-intrinsic-doc.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.