[RFC] SVP64 Cray-style Vectorisation of the OpenPOWER scalar ISA

[lkcl]

(cc'ing Paul Mackerras on this one)

ah, quick question: is there a way to mark the SVP64 functionality as
"experimental" (at runtime)?

longer (quite a bit longer):

the reason i ask is because there is one key 32bit opcode that has to be
added: setvl.

v3.0C [1] and v3.1 make it clear that EXT22 is reserved for "sandbox" use
[2] however learning the lesson from RV custom opcode space it is
critically important that no implementor nor end-users be given the
impression that one implementor has been "officially" (or even unofficially
de-facto) allocated that opcode.

(this is going to be a royal pain, btw).

my recommendation is this: for full-on custom secret internal use only by a
vendor whose hardware ISA modifications (extensions to OpenPOWER) are never
intended to see the public light of day (NVIDIA's secret custom
modifications to the RV ISA, Western Digital's secret custom modifications
to the RV ISA), such vendors should politely but firmly informed that they
are expected to maintain corresponding private hard forks of all
toolchains, with their code *never*, under any circumstances, making it
upstream.

published online to meet their legal obligations under Copyright Law, yes.
merged upstream where it conflicts with other uses of EXT22 and causes no
end of headaches... no.

by complete contrast (SVP64 being at the polar opposite of "secret"), with
the focus being on mass-volume 3D and Video products (smartphones, general
purpose laptops) we anticipate SVP64 being as ubiquitous as AVX512, NEON
and SVE2 are today, and for hundreds of thousands end-users world-wide to
be writing general-purpose programs compiling to SVP64.

consequently there will be extreme end-user pressure to make SVP64
gcc/binutils upstream, and for that EXT22 is completely inappropriate [3]

to make that *abundantly* clear, we need an intermediary period (until
SVP64 has gone through an OPF ISA WG review process [4]) where anything
added is unequivocably marked as "experimental".

what is the best way to do that?

l.

[1] copy of v3.0C easily obtained from http://ftp.libre-soc.org.

[2] the scalar bitmanip extension proposal commpletely takes up an entire
major opcode all on its own, as an unavoidable side-effect of the huge
number of register operands and length of immediates needed, but that's
another story and another bridge to cross

[3] i cannot emphasise enough how massively understated this is.

[4] at which point SVP64 would be allocated "official" opcodes, probably
somewhere in EXT19 for setvl, and it's all safe and ok again at that point