public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: eop Chen <eop.chen@sifive.com>
To: gcc@gcc.gnu.org
Subject: [RFC] Draft release roadmap for RVV v1.0 formal release
Date: Thu, 18 Aug 2022 00:03:21 +0800	[thread overview]
Message-ID: <7604C782-E0CB-41BD-B3F3-947760A653FD@sifive.com> (raw)

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_afjdibr5hpep8nosra3nnd7dgc@group.calendar.google.com>

ICal <https://calendar.google.com/calendar/ical/c_afjdibr5hpep8nosra3nnd7dgc@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



                 reply	other threads:[~2022-08-17 16:03 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7604C782-E0CB-41BD-B3F3-947760A653FD@sifive.com \
    --to=eop.chen@sifive.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).