[RFC] Draft release roadmap for RVV v1.0 formal release

Hi all,

As mentioned in the github issue under rvv-intrinsic-doc, here we want to share our draft roadmap for the formal release.

The main goal of this release is to stablize the using environment of the RVV C intrinsics for the users. So as mentioned in the first RFC letter, we want to consider the completeness of current intrinsic API-s and do minimal fixes and leave the current implementation “as-is” for v1.0.

As always we keep ourselves open minded for new proposals, but based on our take of this stable release, we suggest that anything that breaks backward compatibility or proposals with big change to the current version of RVV C intrinsic should not be considered for this release and we can dwell on them more in the future.

Approximately it would take about half year to work our way to the release. Alongside with existing features and issues, we will want to spare about 3~4 months to gather and address comments in the open community before drafting out a release candidate. Then with respect to the “Ratification Policy” of the RISC-V International, the release candidate will be held 45 days in the public for any last comments. Lastly, we will announce the document freezed and release the formal v1.0.

To keep the release in the public eye, we plan to hold a monthly meeting so everyone can be aware of the remaining features to be done. In the meeting we will also revisit some important details of the intrinsics to make sure we clearly define them in the v1.0 documentation.

With knowledge of other meeting schedules, we are using similar time slot as the PS-ABI. The time may collide with sig-datacenter meetings, but we assume that the participants there may not be too interested in the topic we will be holding. So maybe 9/5 will be a good date to kickoff the first meeting, and then be held on Monday every 4 weeks?

Google calender link


We also need to emphasize before the discussion that a proposal needs to be backed by implementation from either GCC or LLVM, and we can confirm that the proposal is do-able on both compilers.

Based on past participations in the Issue and Pull Request… We have some active developers on both GCC and LLVM. At least we want to seek for their comments and acceptance of the proposed features and decisions before stamping out what should be done.

Regarding current issues, let us first focus on main features we hope to land considering the completeness of RVV C Intrinsic.

  1. Adding an set of fixed point rounding mode intrinsics

    Rationale: It is imaginable that common applications with limited precision will leverage the set of rvv fix-point instructions. Explicit configuration of the rounding mode and saturation is now not possible since the PS-ABI is planning to define them as call clobber. Therefore we need to provide an additional set of fixed point rounding mode intrinsics with rounding mode explicitly specified in the function name, just like the policy intrinsics added recently (#137).

    @arcbbb (Shih-Po Hung) have raised such issue in #144 and we think is a good starting point for discussion. His proposal seeks to replace the current intrinsics, but with some second thought, we prefer extending more intrinsics rather than replace current ones since this will break backward compatibility. We are open for discussion and more comments in the meetings and offline in the issue.

  2. Adding reinterpret_cast between vector mask register and other integer type m1 register

    Rationale: There has been issue raised such that users of the intrinsic may want to convert mask vector registers to m1 integer type vector registers (#69).

    We think this is a reasonable demand but we also want to seek for use-cases to back up the addition of this feature. An issue has been opened in #156 and hope to collect input from the community. Please consider sharing your thoughts there regarding this issue.

Other miscellaneous issues we hope to resolve before v1.0 are the following. We list our proposal in below and seek for more comments.

  1. Redundancy about for “LMUL truncate and extension functions” (#115)

    Brief: The issue proposed to remove the “LMUL truncate and extension functions” since we already have “vector insert and extract functions”.

    Proposal: At this stage where we are releasing a v1.0. We propose to only expand and not remove existing API-s since it may have already attracted some users.

  2. Compatibility with multiple RISCV vector standards (#22)

    Brief: The issue proposed to add support for v0.71 since it was once a temporal version out in the wild that lead to some implementations of it.

    Proposal: The current RVV intrinsics follow the latest ratified v-spec v1.0 and the v0.7 is not considered as part of the standard. Additionally we also may not want fragmentation to happen on the upstream for RVV intrinsics. So we propose not to consider this and keep RVV C intrinsics aligned with the v-spec.

  3. Vector Intrinsic header file organization (#18)

    Brief: The issue raised question on whether we should define Float16 in the RVV intrinsic header

    Proposal: Based on current implementation in the compiler (LLVM / GCC), maybe we can take a step back and don’t define them in the header and let users use typedef to bridge the usages with the RVV intrinsics as currently LLVM / GCC provides _Float16 / float / double.

    Ultimately these kinds of type define should be iteroperable across different extensions. Thus taking a step back allows future definition that suits across extensions to apply on RVV C intrinsics and we don’t need to change the rvv intrinsic header.

Aside from the features above, we will…

  1. Revamp the documentation to increase readability and follow the v-spec to generate PDF documents in ASCIIDoc format. We will follow-up this item by sharing drafts of the documentation in future open meetings.

  2. Release the intrinsic API generator within SiFive to allow other languages to also leverage this and expand intrinsics on them. Clean-up has started and we will send a PR within next month.

Thank you for reading this long letter. Looking forward to hearing more inputs in the Github issues and the open meeting. All comments and reviews are welcomed and appreciated.


eop Chen

I’m not in invested in RVV but I just want to point out that if you don’t do breaking changes now you probably never will; it only gets harder with time, especially once you declare something a stable API you’re then committed to maintaining it, can only ever add new APIs on top and deprecating existing APIs has a much higher threshold for when it’s acceptable. So in my opinion now is the time to think very carefully about how the API that you want to maintain for the foreseeable future should look, including making any breaking changes needed to get there.

Thank you for raising this concern, Jessica. I think re-invoking this conversation is important for the community.

The question comes to what standard do we consider breaking compatibility?

Some proposal is about restructuring or refactoring the existing implementation (for example #140), backed up with each of their own philosophy or personal taste. Regarding such restructuring proposals, the current implementation is the result of consensus reached across major users. So we may not want to break backward compatibility for such proposals but rather extend wrappers in future versions.

On the other hand, we think that we can dwell more on proposals that affects compiler optimization problems or related to functional issues. An example would be like deciding on how do we add the explicit rounding mode fixed point intrinsics (#147).

We have 2 possible approaches to the problem…

Approach 1: Keep the existing fixed point intrinsics, which don’t specify the rounding mode, and add the new set of explicit fixed-point intrinsics.
Rationale: We can maintain backward compatibility.

The recent release of PS-ABI have defined vxrm and vxsat as “not preserved across calls”. Implicit fixed-point intrinsics will rely on the setting of vxrm, and so in the compiler we will just have to
label them with side-effect and limit them in optimizations. Following this definition, we may come to another approach that will break backward compatibility.

Approach 2: Removing the existing fixed-point intrinsics and add the new set of explicit fixed-point intrinsics
Rationale: Since the implicit fixed-point intrinsics will be limited in optimizations. We won’t have much use-case when the set of explicit fixed-point intrinsics are introduced, we can remove it for simplicity.

In the sense that compiler optimization is now affected by the definition of PS-ABI, such removal that breaks backward compatibility is something we may want to consider. If we decide to remove the existing interface, we have go further in detail on how we can remove it.

2-a: Keep the existing interface in v1.0 and claim that we will attempt to deprecate it in v1.1 if the new existing interface suits the need of the majority.

2-b: Directly remove the existing interface in v1.0 release

Standing at a conservative point of view, breaking backward compatibility is a line we never step over. I also understand that we want the community to move forward with better designs. So back to the question, I think that maybe we should set the bar high for incompatible changes and discuss them one-by-one in the open meetings and issue threads.