[llvm-dev] How to support different versions of RVV ?

[陆旭凡 via llvm-dev]

Hello everyone. RVV 0.10 is now supported on the upstream LLVM RISC-V backend. However, because some RISC-V-based chip manufacturers chose RVV 0.71 version as the vector extension at the beginning, and a large number of chips that supported RVV 0.71 version are taped out. So can the community explore a way or framework to support different versions of RVV?
Best wishes.

[陆旭凡 via llvm-dev]

CC 

陆旭凡 <luxufa...@gmail.com> 于2021年6月28日周一 上午10:04写道：

[ALO via llvm-dev]

Hi,

I think it’s a common issue for multi version for all ISAs
if we want to implement it.

I do not find any code to record the version of isa feature also,
the llvm use the default version by hardcode just only by now :(
Is it reasonable ?

From gcc developer view, it records the version in gcc internal from
command line of isa feature and deal with different purpose of multi versions. 

— Jojo

[Alex Bradbury via llvm-dev]

On Mon, 28 Jun 2021 at 03:04, 陆旭凡 via llvm-dev <llvm...@lists.llvm.org> wrote:
>
> Hello everyone. RVV 0.10 is now supported on the upstream LLVM RISC-V backend. However, because some RISC-V-based chip manufacturers chose RVV 0.71 version as the vector extension at the beginning, and a large number of chips that supported RVV 0.71 version are taped out. So can the community explore a way or framework to support different versions of RVV?

Hi - please see here
<https://lists.llvm.org/pipermail/llvm-dev/2020-January/138364.html>
for a discussion on the standard policy for accepting not-yet-ratified
extensions. In the ideal case we wouldn't need to support pre-ratified
versions of the specification (as you've noted, the V support is
currently behind an experimental flag and we track the latest version
of the spec). However, I recognise there are cases where we may need
to be more flexible. The question comes down to how many potential
users there would be for RVV 0.71 support, who would be committing
resources to maintaining, and a consideration of any other costs of
trying to support multiple incompatible RVV versions simultaneously.

Do you have any more information on the chips targeting RVV 0.71?

Best,

Alex
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[ALO via llvm-dev]

— Jojo

在 2021年7月5日 +0800 PM8:23，Alex Bradbury via llvm-dev <llvm...@lists.llvm.org>，写道：

On Mon, 28 Jun 2021 at 03:04, 陆旭凡 via llvm-dev <llvm...@lists.llvm.org> wrote:

Hello everyone. RVV 0.10 is now supported on the upstream LLVM RISC-V backend. However, because some RISC-V-based chip manufacturers chose RVV 0.71 version as the vector extension at the beginning, and a large number of chips that supported RVV 0.71 version are taped out. So can the community explore a way or framework to support different versions of RVV?

Hi - please see here
<https://lists.llvm.org/pipermail/llvm-dev/2020-January/138364.html>
for a discussion on the standard policy for accepting not-yet-ratified
extensions. In the ideal case we wouldn't need to support pre-ratified
versions of the specification (as you've noted, the V support is
currently behind an experimental flag and we track the latest version
of the spec). However, I recognise there are cases where we may need
to be more flexible. The question comes down to how many potential
users there would be for RVV 0.71 support, 

As far as I know, some computing libs like OpenCV [1], OpenBLAS [2], and ComputerLibrary
have implement the RVV 0.7.1. Also some HW core/boards with RVV 0.7.1 like D1 [3], RVB-ICE
have been release from allwinnertech, T-HEAD :)

[1] https://github.com/opencv/opencv/wiki/OpenCV-RISC-V
[2] https://github.com/xianyi/OpenBLAS
[3] https://d1.docs.allwinnertech.com

who would be committing
resources to maintaining, and a consideration of any other costs of
trying to support multiple incompatible RVV versions simultaneously.

I think the vendor who implements the RVV 0.7.1 should to support/fix

multiple incompatible RVV versions simultaneously.

It’s benefit also for all vendors if community encourages to cover
usefull specs :)