Compatibility with multiple RISCV vector standards

[rjiejie]

AFAK，the riscv vector 0.7.1 is stable version like long term version of Linux kernel,

we should to consider that the functions can cover multiple version of vector spec :)

[kito-cheng]

Hi @rjiejie :
My understanding is linux kernel won't accept an extension if it's not frozen or ratified [1], and GNU toolchain also following same rule too, so I think we might just keep upgrading until vector extension frozen or ratified.

[1] https://lkml.org/lkml/2019/11/22/2169

[kito-cheng]

Oh, seems like I misunderstanding, you are metaphor that's like long term version of Linux kernel, not talking about linux kernel itself.

But upstream won't support those version, so personally I think it's not so useful to maintain multiple version of intrinsic spec.

[rdolbeau]

There may be some test/validation/demo hardware using intermediate versions of V, but there won't be a 'production' version with a non-ratified version of the specification, at least not from the EPI side.

You need well-defined, agreed-upon specifications & a thriving software ecosystem to be able to define something as 'production-ready', and start exploiting high-performance silicon. To give you an idea, Intel made the final specifications, compiler & emulator available for nearly two years before AVX-512 was available in silicon with Knight Landings. Similar for SVE, specifications & toolchain from Arm were around for at least two years before A64FX started running code. That's what you need to make sure a) the toolchain works b) the software will be there when the hardware is available c) the hardware actually behave as advertised on a large variety of codes.

[Hsiangkai]

Hi @rjiejie,

Indeed, when we discussed the RFC, we only considered v0.8 and later. The RFC lists naming rules and exceptional cases for the function lists. I do not dig into v0.7.1. Could you help us to point out the incompatible parts between v0.7.1 and these guidelines in the RFC? Maybe you could help us to create a version for v0.7.1 and generate the function lists for v0.7.1. We could create a branch for it.

[rdolbeau]

@Hsiangkai @rjiejie It might be nice to have some level of compatibility with old drafts, but is it really useful in practice? Everything is going to move to whatever turns out to be ratified. Whomever is going forward with v0.7.1 hardware is going to do it for testing purpose only presumably, and will only need enough software to validate the silicon - not for long-term support.

So I tend to agree with @kito-cheng that it's probably not worth the effort.

[Hsiangkai]

I agree. We will not maintain the documents for v0.7.1. If @rjiejie thinks it is necessary to have it, they need to maintain it by themselves. I could help them to create a branch for v0.7.1. here.

[rjiejie]

Hi @rjiejie,

Indeed, when we discussed the RFC, we only considered v0.8 and later. The RFC lists naming rules and exceptional cases for the function lists. I do not dig into v0.7.1. Could you help us to point out the incompatible parts between v0.7.1 and these guidelines in the RFC? Maybe you could help us to create a version for v0.7.1 and generate the function lists for v0.7.1. We could create a branch for it.

Thank you, I will dig difference detailed with a short time :)

[rjiejie]

I agree. We will not maintain the documents for v0.7.1. If @rjiejie thinks it is necessary to have it, they need to maintain it by themselves. I could help them to create a branch for v0.7.1. here.

Hi @Hsiangkai ,

Thanks again.

A little of instructions are deleted from the first stable spec v0.7.1 to the latest,
we should add the the following interface to the RFC to cover all vector specs :)

And for future of vector spec forwarding, we should consider all release vector specs. 
We could use some compiler supported macro to identify the specific interfaces.

Also we could do this part work with you to maintain all vector spec interface in the RFC
if there are much work to do with it.

The following are absent interfaces from the first stable spec.

Integer Extract Instruction:

vext.x.v

Vector Single-Width Averaging Add and Subtract:

vaadd.vi

Vector Widening Saturating Scaled Multiply-Add:

vwsmaccu.vv
vwsmaccu.vx

vwsmacc.vv
vwsmacc.vx

vwsmaccsu.vv
vwsmaccsu.vx

vwsmaccus.vx

Vector Floating-Point Compare Instructions:

vmford.vv
vmford.vf

[Hsiangkai]

I agree. We will not maintain the documents for v0.7.1. If @rjiejie thinks it is necessary to have it, they need to maintain it by themselves. I could help them to create a branch for v0.7.1. here.

Hi @Hsiangkai ,

Thanks again.

A little of instructions are deleted from the first stable spec v0.7.1 to the latest,
we should add the the following interface to the RFC to cover all vector specs :)

And for future of vector spec forwarding, we should consider all release vector specs. 
We could use some compiler supported macro to identify the specific interfaces.

Also we could do this part work with you to maintain all vector spec interface in the RFC
if there are much work to do with it.

The following are absent interfaces from the first stable spec.

Integer Extract Instruction:

vext.x.v

Vector Single-Width Averaging Add and Subtract:

vaadd.vi

Vector Widening Saturating Scaled Multiply-Add:

vwsmaccu.vv
vwsmaccu.vx

vwsmacc.vv
vwsmacc.vx

vwsmaccsu.vv
vwsmaccsu.vx

vwsmaccus.vx

Vector Floating-Point Compare Instructions:

vmford.vv
vmford.vf

I have created a branch, v0.7.1, for you. Could you help us to update the documents to align to v0.7.1 in that branch?

[eopXD]

The current RVV intrinsic follows the latest ratified v-spec v1.0 and the implementation for v0.7 is not in the considered as part of the standard. Maybe we can close this since the current status works for the majority?

Any thoughts on this?

[eopXD]

The intrinsics implement the ratified RISC-V "V" extension.