Introduce vendor prefix for Rivos custom extensions

[preames]

This change reserves the vendor prefix "rv." for Rivos's custom extensions.

[TommyMurphyTM1234]

Might "rv" perhaps get confused with official "RISC-V" standard extensions?

[preames]

Might "rv" perhaps get confused with official "RISC-V" standard extensions?

The mnemonics for standard extensions are not prefixed.

[TommyMurphyTM1234]

Might "rv" perhaps get confused with official "RISC-V" standard extensions?

The mnemonics for standard extensions are not prefixed.

I appreciate that, but isn't it possible that some casual observers won't know that and might mistakenly assume that "rv" prefixed extensions might be official/standard/non-proprietary RISC-V? Especially since "RV" is so widely used as an informal way to refer to RISC-V features in general. An easy way to eliminate the possibility of such confusion might be by using a different prefix here?

[cmuellner]

We talked about this in the SIG Toolchain call today.

I acknowledge the potential for confusion with an rv. prefix.
However, vendor code is not expected to be emitted without explicitly enabling it (similar arguments apply to other occurrences of vendor instructions like hand-written assembly).

Where it might cause confusion is in the intrinsic names.
There, we have a prefix of __riscv_ followed by the vendor prefix.
With accepting rv, we could get intrinsics like __riscv_rv_vadd_vv_i8m1() (similar to __riscv_vadd_vv_i8m1).

I stated that I wouldn't block this PR, but I'd like to hear opinions from GCC and LLVM maintainers on this.

[cmuellner]

The consensus in the RISC-V LLVM sync-up call (lead by @asb) was to accept this.

@kito-cheng, any opinion here?