[PATCH] D142094: [Clang][Doc] Add release note for changes for the RVV intrinsics

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.

In D142094#4070856 <https://reviews.llvm.org/D142094#4070856>, @eopXD wrote:

> In D142094#4065611 <https://reviews.llvm.org/D142094#4065611>, @asb wrote:
>
>> In D142094#4065175 <https://reviews.llvm.org/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.



================
Comment at: clang/docs/ReleaseNotes.rst:818
+  `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 experiment. The RVV
+  C Intrinsic Task Group is working towards a ratified v1.0.
----------------
experiment => development


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D142094/new/

https://reviews.llvm.org/D142094