[DOC] Specify OCP types representation

[MrSidims]

Extension spec: KhronosGroup/SPIRV-Registry#343

[MrSidims]

@svenvh please take a look if such representation makes sense

[svenvh]

Left some initial thoughts and nits.

[MrSidims]

@Keenuts @michalpaszkowski please also take a look as I plan to introduce the extension to the SPIR-V backend as well, and contact for the frontends should be identical for both SPIR-V generators.

Remaining TODOs:

1. Way to make it working with cooperative matrices. Currently internally I'm using bitmasks on the place of cooperative matrix operands of OpCoorerativeMatrixMulAddKHR, but it barely acceptable solution as some might claim the same bits for different purposes;
2. Way to represent SaturatedToLargestFloat8NormalConversionEXT. There are 2 considirations:
   a. (used in internal implementation) a new builtin-like function for clamp conversions - quite straight forward and robust solution;
   b. spirv.Decorations metadata attached to a one of the appropriate conversion buitins described in this PR - it will work out of a box for the translator, but in general relying semantics on metadata attached to an instruction is not a great design, though here it should work, as it would be attacked on an external function call and middle end transformations should not touch such call.

[Keenuts]

@Keenuts @michalpaszkowski please also take a look as I plan to introduce the extension to the SPIR-V backend as well, and contact for the frontends should be identical for both SPIR-V generators.

Shoud this be an RFC in discourse since it's about how to represent something in the LLVM IR?
From a quick look at other float type additions, seems like the suggested form for those are either opaque target types or i8 as long as it's storage-only.
If we go the i8 way, this means we'll have to do some additional type scavenging to correctly lower the i8 types to either a SPV Int8 or the E4M3/E5M2 type no?

[MrSidims]

Shoud this be an RFC in discourse since it's about how to represent something in the LLVM IR?

Sure, I can open one.

From a quick look at other float type additions, seems like the suggested form for those are either opaque target types

SPV_EXT_float8 specification allows to have conversion instructions and LLVM won't allow to have target extension type input to fptrunc and other instructions. So we have to introduce builtins or intrinsics to make it working.

or i8 as long as it's storage-only. If we go the i8 way, this means we'll have to do some additional type scavenging to correctly lower the i8 types to either a SPV Int8 or the E4M3/E5M2 type no?

Kind of. For all of the instructions, with an exception of conversions and cooperative-matrix related instructions, it's fine to leave the value be i8. For conversions and matrices - we can insert a bitcast right before (and after if necessary) the use of fp8 value. In this case we won't actually scavenge any type information before lowering to SPIR-V and it won't introduce extra complexity for lowering (apart of necessity to de-mangle the builtins). I actually have an internal implementation for this, just need to make it 'open-source ready' (but it doesn't mean, that I'm not open to change it - I'm keen to adjust it according to the feedback I can get here or elsewhere).

[MrSidims]

Created https://discourse.llvm.org/t/rfc-spir-v-way-to-represent-float8-in-llvm-ir/87758