[Clang][Doc] Add release note for changes of the RVV intrinsics

[eopXD]

These changes described are based on patch(es) under review. This patch should land after D142085.

[eopXD]

@asb I just saw the cancellation of the sync-up call today. Regarding the branch out on 01/24 I think it would be good to have these incompatible changes into LLVM 16.

[asb]

In D142094#4065175, @eopXD wrote:

@asb I just saw the cancellation of the sync-up call today. Regarding the branch out on 01/24 I think it would be good to have these incompatible changes into LLVM 16.

Sorry for missing there were open questions about this. I won't uncancel the meeting at this point as I think that will just cause more confusion.

What does GCC currently do about these intrinsics? I think the obvious concern would be that by continuing to alter these intrinsics across releases, we're extending the compatibility issue.

Though without RVV 1.0 being agreed yet, I don't see any options other than just documenting where we're at and noting that more changes are possible (as this change does), or alternatively moving the intrinsics to an experimental flag until they're unexperimental.

[eopXD]

In D142094#4065611, @asb wrote:

In D142094#4065175, @eopXD wrote:

@asb I just saw the cancellation of the sync-up call today. Regarding the branch out on 01/24 I think it would be good to have these incompatible changes into LLVM 16.

Sorry for missing there were open questions about this. I won't uncancel the meeting at this point as I think that will just cause more confusion.

What does GCC currently do about these intrinsics?

GCC is targeting to support v1.0 in the next release. The v1.0 intrinsics, excluding the rounding mode (vxrm, frm) and exception flag (vxsat, fflag) intrinsics, should be ones that LLVM have after the above changes have landed.

I think the obvious concern would be that by continuing to alter these intrinsics across releases, we're extending the compatibility issue.

Yes I agree with you. This is the main reason I am trying to have these incompatible changes be landed in LLVM 16.

Though without RVV 1.0 being agreed yet, I don't see any options other than just documenting where we're at and noting that more changes are possible (as this change does), or alternatively moving the intrinsics to an experimental flag until they're unexperimental.

The simplification [0] and __riscv_ [1] is discussed across and have converged. I understand it is a procedural problem that we want the specification be established first, but we also have to conform to the release date of LLVM 16.

[0] https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/186
[1] https://github.com/riscv-non-isa/riscv-c-api-doc/pull/31

[kito-cheng]

As a RISC-V GCC maintainer: GCC 14 is targeting on RVV intrinsic 1.0, but segment load store and rounding mode stuff might not meet the release, so the status will be pretty close to clang/LLVM (with @eopXD's changes, __riscv_ prefix and those simplification stuffs).

[asb]

In D142094#4070856, @eopXD wrote:

In D142094#4065611, @asb wrote:

In D142094#4065175, @eopXD wrote:

@asb I just saw the cancellation of the sync-up call today. Regarding the branch out on 01/24 I think it would be good to have these incompatible changes into LLVM 16.

Sorry for missing there were open questions about this. I won't uncancel the meeting at this point as I think that will just cause more confusion.

What does GCC currently do about these intrinsics?

GCC is targeting to support v1.0 in the next release. The v1.0 intrinsics, excluding the rounding mode (vxrm, frm) and exception flag (vxsat, fflag) intrinsics, should be ones that LLVM have after the above changes have landed.

I think the obvious concern would be that by continuing to alter these intrinsics across releases, we're extending the compatibility issue.

Yes I agree with you. This is the main reason I am trying to have these incompatible changes be landed in LLVM 16.

Though without RVV 1.0 being agreed yet, I don't see any options other than just documenting where we're at and noting that more changes are possible (as this change does), or alternatively moving the intrinsics to an experimental flag until they're unexperimental.

The simplification [0] and __riscv_ [1] is discussed across and have converged. I understand it is a procedural problem that we want the specification be established first, but we also have to conform to the release date of LLVM 16.

[0] https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/186
[1] https://github.com/riscv-non-isa/riscv-c-api-doc/pull/31

Thanks for the answers. That all makes sense to me and it sounds like shipping what we have is probably the best option at this point. I'm happy to trust your judgement on the extent to which the RVV intrinsics have converged. Let's just keep in mind the option to move bits of the intrinsics to an experimental flag if we know it's very likely to change in the future.

Thanks Kito for confirming the GCC status / plans.

clang/docs/ReleaseNotes.rst

154

experiment => development

[eopXD]

Address comment from Alex.

[eopXD]

This was cherry-picked into the release branch of LLVM 16. Closing the patch.

clang/docs/ReleaseNotes.rst

 CUDA Support in Clang
 ---------------------
 
 LoongArch Support in Clang
 --------------------------
 
 RISC-V Support in Clang
 -----------------------
+- An overall simplification of the RISC-V Vector intrinsics are done. The
+  simplification is based on
+  `riscv-non-isa/rvv-intrinsic-doc#186 <https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/186>`_.
+- Intrinsics of `vcompress` and `vmerge` have been adjusted to have interfaces
+  be aligned among `vvm`, `vxm` intrinsics. The adjustment is base on
+  `riscv-non-isa/rvv-intrinsic-doc#185 <https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/185>`_.
+- All RISC-V Vector intrinsics now share a `__riscv_` prefix, based on the
+  naming convention defined by
+  `riscv-non-isa/riscv-c-api-doc#31 <https://github.com/riscv-non-isa/riscv-c-api-doc/pull/31>`_.
+- Note that the RISC-V Vector C intrinsics are still under development. The RVV
+  C Intrinsic Task Group is working towards a ratified v1.0.
 
 X86 Support in Clang
 --------------------
 
 WebAssembly Support in Clang
 ----------------------------
 
 DWARF Support in Clang