|
Hi,
We, EPI, SiPearl, and SiFive, have come out with a RFC for vector intrinsics. Although there are still some issues under discussion, we think it is time to publish the document to collect more feedback from the community. You could access the documents from the github repository[0].
In this RFC[1], we defined the type system, programming interface and naming rules for vector intrinsics in the C language.
Currently, there are a few issues[2] under discussion.
- With or without `vl` argument in the intrinsic interface.
- C operators for scalable vector types.
- Vector types for segment load/store.
- Fractional LMUL representation.
We need your opinions and feedback about these issues. Besides these issues, welcome any feedback about vector intrinsic design.
[0] https://github.com/sifive/rvv-intrinsic-doc/
[1] https://github.com/sifive/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md
[2] https://github.com/sifive/rvv-intrinsic-doc/issues
|
|
|
can you perhaps explain how the vector operands are to be used/allocated?
ie, it appears you wish to use the type system to name vector registers, but there is no limit on these so there must be some implicit register allocation and behaviour when running out.
also, can you please add a few simple convenience functions for copying data between these vector register types and standard C arrays, eg to make debug and things like printf() of a vector easier? I’m thinking something like: int64_t foo[MVL]; foo = toArray(vs1);
finally, adding a few standard names like MVL (though these may be defined by a standard execution sequence which extracts AVL at runtime from the implementation) will aid readability and portability.
guy
On Thu, May 7, 2020 at 9:15 AM Kai Wang < kai.wang@...> wrote:
Hi,
We, EPI, SiPearl, and SiFive, have come out with a RFC for vector intrinsics. Although there are still some issues under discussion, we think it is time to publish the document to collect more feedback from the community. You could access the documents from the github repository[0].
In this RFC[1], we defined the type system, programming interface and naming rules for vector intrinsics in the C language.
Currently, there are a few issues[2] under discussion.
- With or without `vl` argument in the intrinsic interface.
- C operators for scalable vector types.
- Vector types for segment load/store.
- Fractional LMUL representation.
We need your opinions and feedback about these issues. Besides these issues, welcome any feedback about vector intrinsic design.
[0] https://github.com/sifive/rvv-intrinsic-doc/
[1]
[2] https://github.com/sifive/rvv-intrinsic-doc/issues
|
|
|
On Fri, May 8, 2020 at 1:47 AM Guy Lemieux < glemieux@...> wrote:
can you perhaps explain how the vector operands are to be used/allocated?
ie, it appears you wish to use the type system to name vector registers, but there is no limit on these so there must be some implicit register allocation and behaviour when running out.
How many registers will be used for a type depends on the LMUL for the type when LMUL >= 1. For example, vint32m1_t will occupy one register and vint16m2_t will occupy two registers and the register number will be aligned to an even number. If the registers are running out, we will use stack as the spilling space.
also, can you please add a few simple convenience functions for copying data between these vector register types and standard C arrays, eg to make debug and things like printf() of a vector easier? I’m thinking something like: int64_t foo[MVL]; foo = toArray(vs1);
I have created a new issue for your request.
finally, adding a few standard names like MVL (though these may be defined by a standard execution sequence which extracts AVL at runtime from the implementation) will aid readability and portability.
guy
On Thu, May 7, 2020 at 9:15 AM Kai Wang < kai.wang@...> wrote:
Hi,
We, EPI, SiPearl, and SiFive, have come out with a RFC for vector intrinsics. Although there are still some issues under discussion, we think it is time to publish the document to collect more feedback from the community. You could access the documents from the github repository[0].
In this RFC[1], we defined the type system, programming interface and naming rules for vector intrinsics in the C language.
Currently, there are a few issues[2] under discussion.
- With or without `vl` argument in the intrinsic interface.
- C operators for scalable vector types.
- Vector types for segment load/store.
- Fractional LMUL representation.
We need your opinions and feedback about these issues. Besides these issues, welcome any feedback about vector intrinsic design.
[0] https://github.com/sifive/rvv-intrinsic-doc/
[1]
[2] https://github.com/sifive/rvv-intrinsic-doc/issues
|
|
|
On Thu, May 7, 2020 at 07:28 PM, Kai Wang wrote:
On Fri, May 8, 2020 at 1:47 AM Guy Lemieux < glemieux@...> wrote:
can you perhaps explain how the vector operands are to be used/allocated?
ie, it appears you wish to use the type
system to name vector registers, but there is no limit on these so there must be some implicit register allocation and behaviour when running out.
How many registers will be used for a type depends on the LMUL for the type when LMUL >= 1. For example, vint32m1_t will occupy one register and vint16m2_t will occupy two registers and the register number will be aligned to an even number. If the registers are running out, we will use stack as the spilling space.
also, can you please add a few simple convenience functions for copying data between these vector register types and standard C arrays, eg to make debug and things like printf() of a vector easier? I’m thinking something like:
int64_t foo[MVL]; foo = toArray(vs1);
I have created a new issue for your request.
finally, adding a few standard names like MVL
(though these may be defined by a standard execution sequence which extracts AVL at runtime from the implementation) will aid readability and portability.
I guess MVL is now called VLMAX. We do use the standard names in RVV-0.8 spec. Please let us know if there is anything missing. Thanks!
guy
On Thu, May 7, 2020 at 9:15 AM Kai Wang < kai.wang@...> wrote:
Hi,
We, EPI, SiPearl, and SiFive, have come out with a RFC for vector intrinsics. Although there are still some issues under discussion, we think it is time to publish the document to collect more feedback from the community. You could access the documents from the github repository[0].
In this RFC[1], we defined the type system, programming interface and naming rules for vector intrinsics in the C language.
Currently, there are a few issues[2] under discussion.
- With or without `vl` argument in the intrinsic interface.
- C operators for scalable vector types.
- Vector types for segment load/store.
- Fractional LMUL representation.
We need your opinions and feedback about these issues. Besides these issues, welcome any feedback about vector intrinsic design.
[0] https://github.com/sifive/rvv-intrinsic-doc/
[1]
[2] https://github.com/sifive/rvv-intrinsic-doc/issues
|
|
|
can you perhaps explain how the vector operands are to be used/allocated?
ie, it appears you wish to use the type system to name vector registers, but there is no limit on these so there must be some implicit register allocation and behaviour when running out.
sorry I wasn’t clear.
the data types, eg vint64m1_t, are for data elements.
all of the example API definitions also use these same element data types as arguments, but they should be using a data type corresponding of to a vector of elements.
the example code (sgemm, saxpy) uses pointers to these data elements as the vector data types, where the underlying memory has been previously allocated somehow. these examples are flawed and need to show how to connect sequences of vector compute instructions together in a way that does not force every vector result vd to be written back to memory.
the ability to create and use pointers to vectors of elements, and to individual elements, makes the process of compilation harder. it has to detect all of these accesses and insert vector stores or insert vector element extract instructions because of pointer dereferences. yet, this code doesn’t even use the suggested vector element data types, so it will be a challenge if not impossible for the compiler.
instead, vectors should be allocated as an abstract entity that requires accessor methods to set/get individual elements.
without this, every vector compute instruction is going to need to do two vector loads before and one vector store after execution of the vector operation.
this is related to issue #17. the array style is most natural. the size of the array should not be a parameter, it should be the size of the entire physical register (?LMUL*VLMAX bytes?)
|
|
|
On Fri, May 8, 2020 at 1:42 PM Guy Lemieux < glemieux@...> wrote:
can you perhaps explain how the vector operands are to be used/allocated?
ie, it appears you wish to use the type system to name vector registers, but there is no limit on these so there must be some implicit register allocation and behaviour when running out.
sorry I wasn’t clear.
the data types, eg vint64m1_t, are for data elements.
No, the data types are for a vector of elements.
all of the example API definitions also use these same element data types as arguments, but they should be using a data type corresponding of to a vector of elements.
The arguments are vectors of elements, not element data types.
the example code (sgemm, saxpy) uses pointers to these data elements as the vector data types, where the underlying memory has been previously allocated somehow. these examples are flawed and need to show how to connect sequences of vector compute instructions together in a way that does not force every vector result vd to be written back to memory.
the ability to create and use pointers to vectors of elements, and to individual elements, makes the process of compilation harder. it has to detect all of these accesses and insert vector stores or insert vector element extract instructions because of pointer dereferences. yet, this code doesn’t even use the suggested vector element data types, so it will be a challenge if not impossible for the compiler.
instead, vectors should be allocated as an abstract entity that requires accessor methods to set/get individual elements.
without this, every vector compute instruction is going to need to do two vector loads before and one vector store after execution of the vector operation.
this is related to issue #17. the array style is most natural. the size of the array should not be a parameter, it should be the size of the entire physical register (?LMUL*VLMAX bytes?)
|
|
|
Hi,
We (Andes) have also been working on RVV intrinsics with our lead customers for a while, and we appreciate that you published this RFC to spur discussion about vector intrinsics.
After reviewing the RFC, we found it's very similar to our approach. You have some good ideas which we don’t have, but we would also like and present some key benefits in our approach for discussion. Hopefully, together we can converge into a better RVV intrinsic standard:
Our vector types also encode SEW and LMUL into the names, but they have a slightly shorter form, e.g. vi32m1_t, vf64m1_t, which is more consistent with the naming of intrinsic functions. We also encode MLEN into vector mask types but they are named vmaskN_t instead of vboolN_t, and we also provide some user-friendly typedefs so users can derive the mask type from the vector type, e.g.:
typedef vmask8_t vmask_i8m1_t;typedef vmask8_t vmask_i16m2_t; Our intrinsic functions are overloaded over different vtype whenever possible, which roughly corresponds to the _Generic interface in the RFC.
For instructions executed under a mask, it is overloaded under the same name by providing a mask argument and an optional maskedoff arguments after the operands. If the maskedoff argument is not given, masked off elements have undefined values. Both implicit and explicit VL passing are supported. For the latter case, intrinsics accept an optional avl argument, and VL is not changed if avl is not provided. We try to overload intrinsics that are similar in semantics whenever possible. For example, both vmin and vminu are overloaded as vmin, as the extra u suffix to denote signedness, which is significant at instruction-level, has already been encoded in the input types. Based on the previous points, an intrinsic function has the following forms: vop(vs1, vs2)
vop(vs1, vs2, mask)
vop(vs1, vs2, mask, maskedoff)
vop(vs1, vs2, avl)
vop(vs1, vs2, mask, avl)
vop(vs1, vs2, mask, maskedoff, avl)
Our intrinsic for vsetvl takes three arguments: avl, sew and lmul, instead of providing functions with different vtype. This retains the flexibility where programmers can choose vtype based on a runtime value, and compilers can optimize vsetvl with constant sew and lmul arguments to vsetvli instruction.
Now, onto the RFC itself:
It seems that many of the exceptions in naming are caused by the fact that functions are encoded by their return type, and some intrinsics can produce the same output type under different vtype settings. If the function is encoded by the vtype when the instruction is executed, the naming scheme could be simplified. It is also more consistent that an intrinsic's type suffix must be the same as the matching vsetvl (which is not the case for widening intrinsics in the RFC). The non-overloaded vmadc_{vv,vx,vvm,vxm} functions in the RFC also needs to encode the input type, e.g. vmadc_vvm_i8m1_v8. Again, this exception would not be needed if intrinsics are encoded by current vtype instead of return type. vwmul_{vv,vx}_u* intrinsics should have be renamed to vwmulu to match the instruction mnemonic.
In the C11 generic version, vmv_v_x, vfmv_v_f cannot be overloaded based on the scalar type alone, since it could be splatted into vector types with different LMUL. The RFC says that configuration setting intrinsics should return an opaque type _VL_T. This is weird as the user must obtain a _VL_T value from vsetvl, which when used by explicit VL setting intrinsics will be set by a vsetvl again (unless removed by a compiler pass). As a low-level interface, it should just return a size_t and leave the VL abstraction to higher-level programming models. The RFC talks about types and functions for segment load/stores, but such functions are missing from the intrinsics list. vcopy and vsplat are mentioned but are not in the function list. Also, is it necessary to provide the vcopy intrinsics when users can just assign vectors with = operator?
Both vmacc and vmadd instructions are merged into a single vma intrinsic in the RFC. However, they are still independently listed in the function list. Also, should vnmsac and vnmsub also be merged? Both vzero and vundefined shows prototype with the non-existent vfloat8m*_t type. The sample code shows load/store by dereferencing pointers to vector types. If those operations are supported, it should be documented in the RFC. The name of the intrinsic header file (the sample code uses riscv_header.h) also needs to be documented. Finally, the RFC says that it is based on the v0.8 version of RVV specification, but it seems that some changes in v0.9 have slipped through, e.g. the removal of widening/narrowing load/stores and the introduction of vfslide1up. It would be easier to track and reference if it is pinned to one specific version.
On Fri, May 8, 2020 at 12:15 AM, Kai Wang wrote:
> Hi,
>
>
> We, EPI, SiPearl, and SiFive, have come out with a RFC for vector
> intrinsics. Although there are still some issues under discussion, we think
> it is time to publish the document to collect more feedback from the
> community. You could access the documents from the github repository[0].
>
>
> In this RFC[1], we defined the type system, programming interface and
> naming rules for vector intrinsics in the C language.
>
>
> Currently, there are a few issues[2] under discussion.
>
> 1. With or without vl argument in the intrinsic interface.
> 2. C operators for scalable vector types.
> 3. Vector types for segment load/store.
> 4. Fractional LMUL representation.
>
> We need your opinions and feedback about these issues. Besides these issues,
> welcome any feedback about vector intrinsic design.
>
>
> [0] https://github.com/sifive/rvv-intrinsic-doc/
>
> [1]
> https://github.com/sifive/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md
>
> [2] https://github.com/sifive/rvv-intrinsic-doc/issues
>
|
|
|
Hi all,
Firstly, thanks for the vector intrinsic specification RFC.
It's a very timely proposal that meets exactly the requirements of RISC-V fans.
We have learned a lot from it.
As far as we know, the EPI team has open sourced the vector intrinsic interface implementation on the LLVM project,
and their approach has inspired us a lot. The latest RISCV GCC toolchain does not yet support this feature.
After reviewing the RFC, we found that it's very similar to our implementation.
In order to speed up this proposal and help developers using vector,
we are willing to modify the our implementation based on the RFC.
Based on our implementation, which has passed a lot of tests and application development tests,
I think it will be very helpful to make the vector compiler stable in a short time.
In order to meet the urgent needs of vector developers,
we provide a vector development kit (including prebuild compiler, QEMU simulator, Linux image, user manuals, etc.) on the github.
As RFC moves forward, we will update it in time.
I hope it will be helpful for vector developers, and validates new ideas in RFC. :)
Here is current status of the vector development kit.
Pls feel free to contact with us drectly if you have any questions.
Current status:
* Support vector extension instruction standard 0.7.1, you can download the intrinsic user manual [0]
* Open source qemu [1] that it has supported vector extension instruction standard 0.7.1
* Several code examples to help you use vector intrinsic [2]
* Prebuild tools (compiler, qemu simulator, etc.) [3]
* Quickstart steps can be found from our github [4]
* All source code related to the vector extension instruction of GNU toolchain will be opened in the near future
[0] https://github.com/c-sky/xuantie-vector-demos/blob/master/VectorIntrinsicManual.pdf
[1] https://github.com/romanheros/qemu
[2] https://github.com/c-sky/xuantie-vector-demos/tree/master/test
[3] https://github.com/c-sky/xuantie-vector-demos/blob/master/riscv64-linux-x86_64.tbz2
[4] https://github.com/c-sky/xuantie-vector-demos
在 2020年5月8日 +0800 AM12:18，Kai Wang <kai.wang@...>，写道：
Hi,
We, EPI, SiPearl, and SiFive, have come out with a RFC for vector intrinsics. Although there are still some issues under discussion, we think it is time to publish the document to collect more feedback from the community. You could access the documents from the github repository[0].
In this RFC[1], we defined the type system, programming interface and naming rules for vector intrinsics in the C language.
Currently, there are a few issues[2] under discussion.
- With or without `vl` argument in the intrinsic interface.
- C operators for scalable vector types.
- Vector types for segment load/store.
- Fractional LMUL representation.
We need your opinions and feedback about these issues. Besides these issues, welcome any feedback about vector intrinsic design.
[0] https://github.com/sifive/rvv-intrinsic-doc/
[1] https://github.com/sifive/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md
[2] https://github.com/sifive/rvv-intrinsic-doc/issues
|
|
|
Thanks for your feedback. From your description, it is very similar to SiFive internal design. I totally understood why you have these arguments. There are already lots of discussions in the Github issues[1]. You could find the answers there. However, I still point you to the corresponding issues as the following.
On Thu, May 21, 2020 at 8:46 PM < cmchen@...> wrote: Hi,
We (Andes) have also been working on RVV intrinsics with our lead customers for a while, and we appreciate that you published this RFC to spur discussion about vector intrinsics.
After reviewing the RFC, we found it's very similar to our approach. You have some good ideas which we don’t have, but we would also like and present some key benefits in our approach for discussion. Hopefully, together we can converge into a better RVV intrinsic standard:
Our vector types also encode SEW and LMUL into the names, but they have a slightly shorter form, e.g. vi32m1_t, vf64m1_t, which is more consistent with the naming of intrinsic functions.
I think it is better to have type names consistent with C types. It is just my opinion. If you think your naming rules is better, you could discuss it in the Github issues[1]. There are already some discussions there.
We also encode MLEN into vector mask types but they are named vmaskN_t instead of vboolN_t, and we also provide some user-friendly typedefs so users can derive the mask type from the vector type, e.g.:
typedef vmask8_t vmask_i8m1_t;typedef vmask8_t vmask_i16m2_t; Our intrinsic functions are overloaded over different vtype whenever possible, which roughly corresponds to the _Generic interface in the RFC.
For instructions executed under a mask, it is overloaded under the same name by providing a mask argument and an optional maskedoff arguments after the operands. If the maskedoff argument is not given, masked off elements have undefined values. Both implicit and explicit VL passing are supported. For the latter case, intrinsics accept an optional avl argument, and VL is not changed if avl is not provided. We try to overload intrinsics that are similar in semantics whenever possible. For example, both vmin and vminu are overloaded as vmin, as the extra u suffix to denote signedness, which is significant at instruction-level, has already been encoded in the input types. Based on the previous points, an intrinsic function has the following forms: vop(vs1, vs2)
vop(vs1, vs2, mask)
vop(vs1, vs2, mask, maskedoff)
vop(vs1, vs2, avl)
vop(vs1, vs2, mask, avl)
vop(vs1, vs2, mask, maskedoff, avl)
Our intrinsic for vsetvl takes three arguments: avl, sew and lmul, instead of providing functions with different vtype. This retains the flexibility where programmers can choose vtype based on a runtime value, and compilers can optimize vsetvl with constant sew and lmul arguments to vsetvli instruction.
We also considered about it. However, we decide to encode it in the intrinsics statically. You could see the discussion here[2]. Now, onto the RFC itself:
It seems that many of the exceptions in naming are caused by the fact that functions are encoded by their return type, and some intrinsics can produce the same output type under different vtype settings. If the function is encoded by the vtype when the instruction is executed, the naming scheme could be simplified. It is also more consistent that an intrinsic's type suffix must be the same as the matching vsetvl (which is not the case for widening intrinsics in the RFC).
We decide to encode return types in the intrinsic names. It is easier to know the types if we use intrinsics as arguments. In addition, we think it is better to have consistent names, we create a simple naming rules plus some exceptional cases. You could see the discussion here[3][4].
The non-overloaded vmadc_{vv,vx,vvm,vxm} functions in the RFC also needs to encode the input type, e.g. vmadc_vvm_i8m1_v8. Again, this exception would not be needed if intrinsics are encoded by current vtype instead of return type. vwmul_{vv,vx}_u* intrinsics should have be renamed to vwmulu to match the instruction mnemonic.
In the C11 generic version, vmv_v_x, vfmv_v_f cannot be overloaded based on the scalar type alone, since it could be splatted into vector types with different LMUL. The RFC says that configuration setting intrinsics should return an opaque type _VL_T. This is weird as the user must obtain a _VL_T value from vsetvl, which when used by explicit VL setting intrinsics will be set by a vsetvl again (unless removed by a compiler pass). As a low-level interface, it should just return a size_t and leave the VL abstraction to higher-level programming models.
There are lots of discussions about vl argument[5]. The point of opaque type is if we should permit vl be modified through the additional vl argument.
The RFC talks about types and functions for segment load/stores, but such functions are missing from the intrinsics list. vcopy and vsplat are mentioned but are not in the function list. Also, is it necessary to provide the vcopy intrinsics when users can just assign vectors with = operator?
Both vmacc and vmadd instructions are merged into a single vma intrinsic in the RFC. However, they are still independently listed in the function list. Also, should vnmsac and vnmsub also be merged? Both vzero and vundefined shows prototype with the non-existent vfloat8m*_t type. The sample code shows load/store by dereferencing pointers to vector types. If those operations are supported, it should be documented in the RFC.
It is under discussion about C operators[6]. Under discussion[7].
Finally, the RFC says that it is based on the v0.8 version of RVV specification, but it seems that some changes in v0.9 have slipped through, e.g. the removal of widening/narrowing load/stores and the introduction of vfslide1up. It would be easier to track and reference if it is pinned to one specific version.
There are some bugs in the full intrinsics list. Thanks for pointing them out. We will correct them as soon as possible. Welcome to join the discussion. Thanks for your kindly feedback.
On Fri, May 8, 2020 at 12:15 AM, Kai Wang wrote:
> Hi,
>
>
> We, EPI, SiPearl, and SiFive, have come out with a RFC for vector
> intrinsics. Although there are still some issues under discussion, we think
> it is time to publish the document to collect more feedback from the
> community. You could access the documents from the github repository[0].
>
>
> In this RFC[1], we defined the type system, programming interface and
> naming rules for vector intrinsics in the C language.
>
>
> Currently, there are a few issues[2] under discussion.
>
> 1. With or without vl argument in the intrinsic interface.
> 2. C operators for scalable vector types.
> 3. Vector types for segment load/store.
> 4. Fractional LMUL representation.
>
> We need your opinions and feedback about these issues. Besides these issues,
> welcome any feedback about vector intrinsic design.
>
>
> [0] https://github.com/sifive/rvv-intrinsic-doc/
>
> [1]
> https://github.com/sifive/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md
>
> [2] https://github.com/sifive/rvv-intrinsic-doc/issues
>
|
|
|
Hi all,
Firstly, thanks for the vector intrinsic specification RFC.
It's a very timely proposal that meets exactly the requirements of RISC-V fans.
We have learned a lot from it.
As far as we know, the EPI team has open sourced the vector intrinsic interface implementation on the LLVM project,
and their approach has inspired us a lot. The latest RISCV GCC toolchain does not yet support this feature.
Indeed, the EPI team is the first one to publish their intrinsic interface and implementations. They give us lots of suggestions about the intrinsics design. The RFC could not come out without their help.
After reviewing the RFC, we found that it's very similar to our implementation.
In order to speed up this proposal and help developers using vector,
we are willing to modify the our implementation based on the RFC.
I agree with you. We are also modifying our internal implementation based on this RFC. If you find anything that is not well-defined in the RFC, welcome to your feedback.
If we all agree to follow the RFC, is it better to move the intrinsic RFC to the riscv github, instead of under the sifive github? Do you agree with that? We could work together to come up with the standard intrinsics for RVV with the community.
Based on our implementation, which has passed a lot of tests and application development tests,
I think it will be very helpful to make the vector compiler stable in a short time.
In order to meet the urgent needs of vector developers,
we provide a vector development kit (including prebuild compiler, QEMU simulator, Linux image, user manuals, etc.) on the github.
As RFC moves forward, we will update it in time.
I hope it will be helpful for vector developers, and validates new ideas in RFC. :)
Here is current status of the vector development kit.
Pls feel free to contact with us drectly if you have any questions.
Current status:
* Support vector extension instruction standard 0.7.1, you can download the intrinsic user manual [0]
* Open source qemu [1] that it has supported vector extension instruction standard 0.7.1
* Several code examples to help you use vector intrinsic [2]
* Prebuild tools (compiler, qemu simulator, etc.) [3]
* Quickstart steps can be found from our github [4]
* All source code related to the vector extension instruction of GNU toolchain will be opened in the near future
[0] https://github.com/c-sky/xuantie-vector-demos/blob/master/VectorIntrinsicManual.pdf
[1] https://github.com/romanheros/qemu
[2] https://github.com/c-sky/xuantie-vector-demos/tree/master/test
[3] https://github.com/c-sky/xuantie-vector-demos/blob/master/riscv64-linux-x86_64.tbz2
[4] https://github.com/c-sky/xuantie-vector-demos
在 2020年5月8日 +0800 AM12:18，Kai Wang < kai.wang@...>，写道：
Hi,
We, EPI, SiPearl, and SiFive, have come out with a RFC for vector intrinsics. Although there are still some issues under discussion, we think it is time to publish the document to collect more feedback from the community. You could access the documents from the github repository[0].
In this RFC[1], we defined the type system, programming interface and naming rules for vector intrinsics in the C language.
Currently, there are a few issues[2] under discussion.
- With or without `vl` argument in the intrinsic interface.
- C operators for scalable vector types.
- Vector types for segment load/store.
- Fractional LMUL representation.
We need your opinions and feedback about these issues. Besides these issues, welcome any feedback about vector intrinsic design.
[0] https://github.com/sifive/rvv-intrinsic-doc/
[1] https://github.com/sifive/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md
[2] https://github.com/sifive/rvv-intrinsic-doc/issues
|
|
|
I agree with you. We are also modifying our internal implementation based on this RFC. If you find anything that is not well-defined in the RFC, welcome to your feedback.
If we all agree to follow the RFC, is it better to move the intrinsic RFC to the riscv github, instead of under the sifive github? Do you agree with that? We could work together to come up with the standard intrinsics for RVV with the community.
It’s looks like a better change to move the intrinsic RFC to the riscv github :)
在 2020年5月24日 +0800 AM10:49，Kai Wang <kai.wang@...>，写道：
Hi all,
Firstly, thanks for the vector intrinsic specification RFC.
It's a very timely proposal that meets exactly the requirements of RISC-V fans.
We have learned a lot from it.
As far as we know, the EPI team has open sourced the vector intrinsic interface implementation on the LLVM project,
and their approach has inspired us a lot. The latest RISCV GCC toolchain does not yet support this feature.
Indeed, the EPI team is the first one to publish their intrinsic interface and implementations. They give us lots of suggestions about the intrinsics design. The RFC could not come out without their help.
After reviewing the RFC, we found that it's very similar to our implementation.
In order to speed up this proposal and help developers using vector,
we are willing to modify the our implementation based on the RFC.
I agree with you. We are also modifying our internal implementation based on this RFC. If you find anything that is not well-defined in the RFC, welcome to your feedback.
If we all agree to follow the RFC, is it better to move the intrinsic RFC to the riscv github, instead of under the sifive github? Do you agree with that? We could work together to come up with the standard intrinsics for RVV with the community.
Based on our implementation, which has passed a lot of tests and application development tests,
I think it will be very helpful to make the vector compiler stable in a short time.
In order to meet the urgent needs of vector developers,
we provide a vector development kit (including prebuild compiler, QEMU simulator, Linux image, user manuals, etc.) on the github.
As RFC moves forward, we will update it in time.
I hope it will be helpful for vector developers, and validates new ideas in RFC. :)
Here is current status of the vector development kit.
Pls feel free to contact with us drectly if you have any questions.
Current status:
* Support vector extension instruction standard 0.7.1, you can download the intrinsic user manual [0]
* Open source qemu [1] that it has supported vector extension instruction standard 0.7.1
* Several code examples to help you use vector intrinsic [2]
* Prebuild tools (compiler, qemu simulator, etc.) [3]
* Quickstart steps can be found from our github [4]
* All source code related to the vector extension instruction of GNU toolchain will be opened in the near future
[0] https://github.com/c-sky/xuantie-vector-demos/blob/master/VectorIntrinsicManual.pdf
[1] https://github.com/romanheros/qemu
[2] https://github.com/c-sky/xuantie-vector-demos/tree/master/test
[3] https://github.com/c-sky/xuantie-vector-demos/blob/master/riscv64-linux-x86_64.tbz2
[4] https://github.com/c-sky/xuantie-vector-demos
在 2020年5月8日 +0800 AM12:18，Kai Wang < kai.wang@...>，写道：
Hi,
We, EPI, SiPearl, and SiFive, have come out with a RFC for vector intrinsics. Although there are still some issues under discussion, we think it is time to publish the document to collect more feedback from the community. You could access the documents from the github repository[0].
In this RFC[1], we defined the type system, programming interface and naming rules for vector intrinsics in the C language.
Currently, there are a few issues[2] under discussion.
- With or without `vl` argument in the intrinsic interface.
- C operators for scalable vector types.
- Vector types for segment load/store.
- Fractional LMUL representation.
We need your opinions and feedback about these issues. Besides these issues, welcome any feedback about vector intrinsic design.
[0] https://github.com/sifive/rvv-intrinsic-doc/
[1] https://github.com/sifive/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md
[2] https://github.com/sifive/rvv-intrinsic-doc/issues
|
|
|
toggle quoted message
Show quoted text
I agree with you. We are also modifying our internal implementation based on this RFC. If you find anything that is not well-defined in the RFC, welcome to your feedback.
If we all agree to follow the RFC, is it better to move the intrinsic RFC to the riscv github, instead of under the sifive github? Do you agree with that? We could work together to come up with the standard intrinsics for RVV with the community.
It’s looks like a better change to move the intrinsic RFC to the riscv github :)
在 2020年5月24日 +0800 AM10:49，Kai Wang < kai.wang@...>，写道：
Hi all,
Firstly, thanks for the vector intrinsic specification RFC.
It's a very timely proposal that meets exactly the requirements of RISC-V fans.
We have learned a lot from it.
As far as we know, the EPI team has open sourced the vector intrinsic interface implementation on the LLVM project,
and their approach has inspired us a lot. The latest RISCV GCC toolchain does not yet support this feature.
Indeed, the EPI team is the first one to publish their intrinsic interface and implementations. They give us lots of suggestions about the intrinsics design. The RFC could not come out without their help.
After reviewing the RFC, we found that it's very similar to our implementation.
In order to speed up this proposal and help developers using vector,
we are willing to modify the our implementation based on the RFC.
I agree with you. We are also modifying our internal implementation based on this RFC. If you find anything that is not well-defined in the RFC, welcome to your feedback.
If we all agree to follow the RFC, is it better to move the intrinsic RFC to the riscv github, instead of under the sifive github? Do you agree with that? We could work together to come up with the standard intrinsics for RVV with the community.
Based on our implementation, which has passed a lot of tests and application development tests,
I think it will be very helpful to make the vector compiler stable in a short time.
In order to meet the urgent needs of vector developers,
we provide a vector development kit (including prebuild compiler, QEMU simulator, Linux image, user manuals, etc.) on the github.
As RFC moves forward, we will update it in time.
I hope it will be helpful for vector developers, and validates new ideas in RFC. :)
Here is current status of the vector development kit.
Pls feel free to contact with us drectly if you have any questions.
Current status:
* Support vector extension instruction standard 0.7.1, you can download the intrinsic user manual [0]
* Open source qemu [1] that it has supported vector extension instruction standard 0.7.1
* Several code examples to help you use vector intrinsic [2]
* Prebuild tools (compiler, qemu simulator, etc.) [3]
* Quickstart steps can be found from our github [4]
* All source code related to the vector extension instruction of GNU toolchain will be opened in the near future
[0] https://github.com/c-sky/xuantie-vector-demos/blob/master/VectorIntrinsicManual.pdf
[1] https://github.com/romanheros/qemu
[2] https://github.com/c-sky/xuantie-vector-demos/tree/master/test
[3] https://github.com/c-sky/xuantie-vector-demos/blob/master/riscv64-linux-x86_64.tbz2
[4] https://github.com/c-sky/xuantie-vector-demos
在 2020年5月8日 +0800 AM12:18，Kai Wang < kai.wang@...>，写道：
Hi,
We, EPI, SiPearl, and SiFive, have come out with a RFC for vector intrinsics. Although there are still some issues under discussion, we think it is time to publish the document to collect more feedback from the community. You could access the documents from the github repository[0].
In this RFC[1], we defined the type system, programming interface and naming rules for vector intrinsics in the C language.
Currently, there are a few issues[2] under discussion.
- With or without `vl` argument in the intrinsic interface.
- C operators for scalable vector types.
- Vector types for segment load/store.
- Fractional LMUL representation.
We need your opinions and feedback about these issues. Besides these issues, welcome any feedback about vector intrinsic design.
[0] https://github.com/sifive/rvv-intrinsic-doc/
[1] https://github.com/sifive/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md
[2] https://github.com/sifive/rvv-intrinsic-doc/issues
|
|
|
Hi Kai,
There is a little issue for function lists,
How to compatibility with multiple RISCV vector standards ?
AFAK，the riscv vector 0.7.1 is stable version like long term version of Linux kernel,
we should to consider that the functions can cover multiple version of vector spec :)
在 2020年6月1日 +0800 AM11:20，Kai Wang <kai.wang@...>，写道：
I agree with you. We are also modifying our internal implementation based on this RFC. If you find anything that is not well-defined in the RFC, welcome to your feedback.
If we all agree to follow the RFC, is it better to move the intrinsic RFC to the riscv github, instead of under the sifive github? Do you agree with that? We could work together to come up with the standard intrinsics for RVV with the community.
It’s looks like a better change to move the intrinsic RFC to the riscv github :)
在 2020年5月24日 +0800 AM10:49，Kai Wang < kai.wang@...>，写道：
Hi all,
Firstly, thanks for the vector intrinsic specification RFC.
It's a very timely proposal that meets exactly the requirements of RISC-V fans.
We have learned a lot from it.
As far as we know, the EPI team has open sourced the vector intrinsic interface implementation on the LLVM project,
and their approach has inspired us a lot. The latest RISCV GCC toolchain does not yet support this feature.
Indeed, the EPI team is the first one to publish their intrinsic interface and implementations. They give us lots of suggestions about the intrinsics design. The RFC could not come out without their help.
After reviewing the RFC, we found that it's very similar to our implementation.
In order to speed up this proposal and help developers using vector,
we are willing to modify the our implementation based on the RFC.
I agree with you. We are also modifying our internal implementation based on this RFC. If you find anything that is not well-defined in the RFC, welcome to your feedback.
If we all agree to follow the RFC, is it better to move the intrinsic RFC to the riscv github, instead of under the sifive github? Do you agree with that? We could work together to come up with the standard intrinsics for RVV with the community.
Based on our implementation, which has passed a lot of tests and application development tests,
I think it will be very helpful to make the vector compiler stable in a short time.
In order to meet the urgent needs of vector developers,
we provide a vector development kit (including prebuild compiler, QEMU simulator, Linux image, user manuals, etc.) on the github.
As RFC moves forward, we will update it in time.
I hope it will be helpful for vector developers, and validates new ideas in RFC. :)
Here is current status of the vector development kit.
Pls feel free to contact with us drectly if you have any questions.
Current status:
* Support vector extension instruction standard 0.7.1, you can download the intrinsic user manual [0]
* Open source qemu [1] that it has supported vector extension instruction standard 0.7.1
* Several code examples to help you use vector intrinsic [2]
* Prebuild tools (compiler, qemu simulator, etc.) [3]
* Quickstart steps can be found from our github [4]
* All source code related to the vector extension instruction of GNU toolchain will be opened in the near future
[0] https://github.com/c-sky/xuantie-vector-demos/blob/master/VectorIntrinsicManual.pdf
[1] https://github.com/romanheros/qemu
[2] https://github.com/c-sky/xuantie-vector-demos/tree/master/test
[3] https://github.com/c-sky/xuantie-vector-demos/blob/master/riscv64-linux-x86_64.tbz2
[4] https://github.com/c-sky/xuantie-vector-demos
在 2020年5月8日 +0800 AM12:18，Kai Wang < kai.wang@...>，写道：
Hi,
We, EPI, SiPearl, and SiFive, have come out with a RFC for vector intrinsics. Although there are still some issues under discussion, we think it is time to publish the document to collect more feedback from the community. You could access the documents from the github repository[0].
In this RFC[1], we defined the type system, programming interface and naming rules for vector intrinsics in the C language.
Currently, there are a few issues[2] under discussion.
- With or without `vl` argument in the intrinsic interface.
- C operators for scalable vector types.
- Vector types for segment load/store.
- Fractional LMUL representation.
We need your opinions and feedback about these issues. Besides these issues, welcome any feedback about vector intrinsic design.
[0] https://github.com/sifive/rvv-intrinsic-doc/
[1] https://github.com/sifive/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md
[2] https://github.com/sifive/rvv-intrinsic-doc/issues
|
|
|
Hi all,
A few days ago, we have put the vector development kit (including prebuild compiler, QEMU simulator, Linux image, user manuals, etc.) on the github[0].
Many community friends have reported some very good questions, and we are constantly improving.
Today we are very happy, open source riscv vector extension instruction intrisnic code, everyone can verify that,
We could work together to improve better, you can download it from our github:
git clone https://github.com/c-sky/gcc.git -b gcc-9-rvv
At present, we use a tool to quickly and automatically generate intrinsic interface file, test codes and user manuals.
that can help community to accelerate the development of the riscv vector extension instruction function on the GCC tool.
[0] https://github.com/c-sky/xuantie-vector-demos
在 2020年5月24日 +0800 AM12:30，戎杰杰 <jiejie.rjj@...>，写道：
Hi all,
Firstly, thanks for the vector intrinsic specification RFC.
It's a very timely proposal that meets exactly the requirements of RISC-V fans.
We have learned a lot from it.
As far as we know, the EPI team has open sourced the vector intrinsic interface implementation on the LLVM project,
and their approach has inspired us a lot. The latest RISCV GCC toolchain does not yet support this feature.
After reviewing the RFC, we found that it's very similar to our implementation.
In order to speed up this proposal and help developers using vector,
we are willing to modify the our implementation based on the RFC.
Based on our implementation, which has passed a lot of tests and application development tests,
I think it will be very helpful to make the vector compiler stable in a short time.
In order to meet the urgent needs of vector developers,
we provide a vector development kit (including prebuild compiler, QEMU simulator, Linux image, user manuals, etc.) on the github.
As RFC moves forward, we will update it in time.
I hope it will be helpful for vector developers, and validates new ideas in RFC. :)
Here is current status of the vector development kit.
Pls feel free to contact with us drectly if you have any questions.
Current status:
* Support vector extension instruction standard 0.7.1, you can download the intrinsic user manual [0]
* Open source qemu [1] that it has supported vector extension instruction standard 0.7.1
* Several code examples to help you use vector intrinsic [2]
* Prebuild tools (compiler, qemu simulator, etc.) [3]
* Quickstart steps can be found from our github [4]
* All source code related to the vector extension instruction of GNU toolchain will be opened in the near future
[0] https://github.com/c-sky/xuantie-vector-demos/blob/master/VectorIntrinsicManual.pdf
[1] https://github.com/romanheros/qemu
[2] https://github.com/c-sky/xuantie-vector-demos/tree/master/test
[3] https://github.com/c-sky/xuantie-vector-demos/blob/master/riscv64-linux-x86_64.tbz2
[4] https://github.com/c-sky/xuantie-vector-demos
在 2020年5月8日 +0800 AM12:18，Kai Wang <kai.wang@...>，写道：
Hi,
We, EPI, SiPearl, and SiFive, have come out with a RFC for vector intrinsics. Although there are still some issues under discussion, we think it is time to publish the document to collect more feedback from the community. You could access the documents from the github repository[0].
In this RFC[1], we defined the type system, programming interface and naming rules for vector intrinsics in the C language.
Currently, there are a few issues[2] under discussion.
- With or without `vl` argument in the intrinsic interface.
- C operators for scalable vector types.
- Vector types for segment load/store.
- Fractional LMUL representation.
We need your opinions and feedback about these issues. Besides these issues, welcome any feedback about vector intrinsic design.
[0] https://github.com/sifive/rvv-intrinsic-doc/
[1] https://github.com/sifive/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md
[2] https://github.com/sifive/rvv-intrinsic-doc/issues
|
|
|
Jim Wilson
On Tue, Jun 2, 2020 at 12:41 AM "戎杰杰 <jiejie.rjj@...> wrote: How to compatibility with multiple RISCV vector standards ?
AFAK，the riscv vector 0.7.1 is stable version like long term version of Linux kernel, The v0.7.1 rvv spec is a draft of a proposal, and has no official status. There are no plans to support it in the upstream GNU toolchain. Support for it was added to qemu, but the current plans are to just drop it when an official rvv spec implementation is available. The v0.7.1 spec should have never been implemented in an ASIC. This is most unfortunate. If we really need support for v0.7.1 in upstream tools, then we are probably going to have to do two completely separate rvv ports, like Altivec and SPE for PowerPC. This is twice as much work to maintain and is going to be an ugly mess. Jim
|
|
|
Hi, Jiejie,
Thank you for the work.
Xianyi
Hi all,
A few days ago, we have put the vector development kit (including prebuild compiler, QEMU simulator, Linux image, user manuals, etc.) on the github[0].
Many community friends have reported some very good questions, and we are constantly improving.
Today we are very happy, open source riscv vector extension instruction intrisnic code, everyone can verify that,
We could work together to improve better, you can download it from our github:
git clone https://github.com/c-sky/gcc.git -b gcc-9-rvv
At present, we use a tool to quickly and automatically generate intrinsic interface file, test codes and user manuals.
that can help community to accelerate the development of the riscv vector extension instruction function on the GCC tool.
[0] https://github.com/c-sky/xuantie-vector-demos
在 2020年5月24日 +0800 AM12:30，戎杰杰 < jiejie.rjj@...>，写道：
Hi all,
Firstly, thanks for the vector intrinsic specification RFC.
It's a very timely proposal that meets exactly the requirements of RISC-V fans.
We have learned a lot from it.
As far as we know, the EPI team has open sourced the vector intrinsic interface implementation on the LLVM project,
and their approach has inspired us a lot. The latest RISCV GCC toolchain does not yet support this feature.
After reviewing the RFC, we found that it's very similar to our implementation.
In order to speed up this proposal and help developers using vector,
we are willing to modify the our implementation based on the RFC.
Based on our implementation, which has passed a lot of tests and application development tests,
I think it will be very helpful to make the vector compiler stable in a short time.
In order to meet the urgent needs of vector developers,
we provide a vector development kit (including prebuild compiler, QEMU simulator, Linux image, user manuals, etc.) on the github.
As RFC moves forward, we will update it in time.
I hope it will be helpful for vector developers, and validates new ideas in RFC. :)
Here is current status of the vector development kit.
Pls feel free to contact with us drectly if you have any questions.
Current status:
* Support vector extension instruction standard 0.7.1, you can download the intrinsic user manual [0]
* Open source qemu [1] that it has supported vector extension instruction standard 0.7.1
* Several code examples to help you use vector intrinsic [2]
* Prebuild tools (compiler, qemu simulator, etc.) [3]
* Quickstart steps can be found from our github [4]
* All source code related to the vector extension instruction of GNU toolchain will be opened in the near future
[0] https://github.com/c-sky/xuantie-vector-demos/blob/master/VectorIntrinsicManual.pdf
[1] https://github.com/romanheros/qemu
[2] https://github.com/c-sky/xuantie-vector-demos/tree/master/test
[3] https://github.com/c-sky/xuantie-vector-demos/blob/master/riscv64-linux-x86_64.tbz2
[4] https://github.com/c-sky/xuantie-vector-demos
在 2020年5月8日 +0800 AM12:18，Kai Wang < kai.wang@...>，写道：
Hi,
We, EPI, SiPearl, and SiFive, have come out with a RFC for vector intrinsics. Although there are still some issues under discussion, we think it is time to publish the document to collect more feedback from the community. You could access the documents from the github repository[0].
In this RFC[1], we defined the type system, programming interface and naming rules for vector intrinsics in the C language.
Currently, there are a few issues[2] under discussion.
- With or without `vl` argument in the intrinsic interface.
- C operators for scalable vector types.
- Vector types for segment load/store.
- Fractional LMUL representation.
We need your opinions and feedback about these issues. Besides these issues, welcome any feedback about vector intrinsic design.
[0] https://github.com/sifive/rvv-intrinsic-doc/
[1] https://github.com/sifive/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md
[2] https://github.com/sifive/rvv-intrinsic-doc/issues
|
|
|
