Hi all, As mentioned in the first RFC letter <https://gcc.gnu.org/pipermail/gcc/2022-August/239234.html>, 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 <https://discourse.llvm.org/t/rfc-drafting-a-formal-v1-0-release-for-rvv-c-intrinsic-api/64220>, 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 <https://docs.google.com/document/d/1-UlaSGqk59_myeuPMrV9gyuaIgnmFzGh5Gfy_tpViwM/edit?usp=sharing>” 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 <https://calendar.google.com/calendar/embed?src=c_afjdibr5hpep8nosra3nnd7...@group.calendar.google.com> ICal <https://calendar.google.com/calendar/ical/c_afjdibr5hpep8nosra3nnd7...@group.calendar.google.com/public/basic.ics> 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 <https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/137>). @arcbbb <https://github.com/arcbbb> (Shih-Po Hung) have raised such issue in #144 <https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/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 <https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/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 <https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/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 <https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/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 <https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/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 <https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/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 interoperable 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. Regards, eop Chen
