From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) by sourceware.org (Postfix) with ESMTPS id D5D6F3858D37 for ; Wed, 17 Aug 2022 16:03:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D5D6F3858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-pg1-x52e.google.com with SMTP id s206so12343179pgs.3 for ; Wed, 17 Aug 2022 09:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=to:date:message-id:subject:mime-version:from:from:to:cc; bh=Zl+LpF+pMvdgYOTNNZm/Y8pby1PVUZPTixPv30J6EsA=; b=J2bSdpJjq+MNRs/CiCPpIDXziu9j2QhO01o1R6n5wfW2BJLZExXCzpOC4mxw3SwyKZ FGcEef/c3ZJwJqvxoN0k6Gzfl4IRUezjhbmXp20Ty+oNe1UCvLEhXNAT/G9QSCF75F81 Fs341xIMPGZXn9p4NYq23HvoQGrS74rk/6kjNzxoABxDNFZx6VpW8MQqdYSLBdmMu8cd OeNtj3QFTfh5JBoOPJBA7Kl/Vhs+Tintf1N9Gy+UJSDaKga6SgTzc+RUIixhyR2MJs37 4k5Pv1SVJ9jrn4BJs13GJ1BWhREeLxGS8C0HC7rfSdEbZEaMr9JAbCBva0pTyKkqz13A ahlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc; bh=Zl+LpF+pMvdgYOTNNZm/Y8pby1PVUZPTixPv30J6EsA=; b=nK+xVUDy60qkdclCYCMqHxJekzflKQmsgbUoEyVkKBxDaJCtIyimDomxRuUCN/SfQf t5hh36HDO0ykrLXpJsj2GdZpzAdcLhvP5mPcArSSu0LV2qkHvfFzb1TC+hnv/7+417m3 0QFQ2Swi72a4cY9gfLBOaop0C0d2pHsYOYtNPIZZpUqLHs5NkhNQawGrcBhYI4GpBF/s rxqXDLVjeRA5rZveUGAVAjauuSuHQ3KD09To0nir5YJRyfaHk2CIieoPGateOxGFcJZP 2iT8Ht1OwmKDmVKB9CT600viiORAxG8GloX8hRZJip4qe7AqbOVzC16GDV+Pic6zr8qN LSsQ== X-Gm-Message-State: ACgBeo0C1FtUw/U1y7gY4f/Hr2ZvKlA4zsTkZQEXsCof205feX9wfMu4 4OU5L3pfSYkV9PGgJhIRgyuxYTWzbkpRug== X-Google-Smtp-Source: AA6agR5vkq8YU2IQsOMOdz9m9ek/X+uVuWGA24Ued+JCLtXKUVpqcp4rKZcnHnz65TUozgSDYMG1hw== X-Received: by 2002:a05:6a00:148c:b0:52e:a630:afc7 with SMTP id v12-20020a056a00148c00b0052ea630afc7mr26269500pfu.0.1660752204869; Wed, 17 Aug 2022 09:03:24 -0700 (PDT) Received: from smtpclient.apple (118-169-30-140.dynamic-ip.hinet.net. [118.169.30.140]) by smtp.gmail.com with ESMTPSA id w6-20020aa79546000000b0052e0e6c76f1sm10704793pfq.0.2022.08.17.09.03.23 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Aug 2022 09:03:24 -0700 (PDT) From: eop Chen Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: [RFC] Draft release roadmap for RVV v1.0 formal release Message-Id: <7604C782-E0CB-41BD-B3F3-947760A653FD@sifive.com> Date: Thu, 18 Aug 2022 00:03:21 +0800 To: gcc@gcc.gnu.org X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_KAM_HTML_FONT_INVALID, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2022 16:03:35 -0000 Hi all, As mentioned in the first RFC letter = , 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 =E2=80=9Cas-is=E2= =80=9D 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 = =E2=80=9CRatification Policy = =E2=80=9D 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 = ICal = 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=E2=80=A6 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. =E2=80=94=E2=80=94=E2=80=94 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. =E2=80=94=E2=80=94=E2=80=94 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 =E2=80=9CLMUL truncate and extension = functions=E2=80=9D (#115 = ) Brief: The issue proposed to remove the =E2=80=9CLMUL truncate and = extension functions=E2=80=9D since we already have =E2=80=9Cvector insert and extract functions=E2=80=9D. 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=E2=80=99t 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=E2=80=99t need to change the RVV intrinsic header. =E2=80=94=E2=80=94=E2=80=94 Aside from the features above, we will=E2=80=A6 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. =E2=80=94=E2=80=94=E2=80=94 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