[libre-riscv-dev] [llvm-dev] RFC: First-class Matrix type

[Jacob Lifshay]

On Thu, Oct 11, 2018 at 1:27 AM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> [off llvm-dev list, link/ref here:
> http://lists.llvm.org/pipermail/llvm-dev/2018-October/126873.html]
>
> On Thu, Oct 11, 2018 at 8:59 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> >
> > This sounds like it would be really useful for 3D Graphics APIs as
> SPIR-V (the Vulkan/OpenCL2.1 intermediate representation) has matrices as
> first-class types. This will promote round-trip-ability. I have also heard
> that RISC-V's V extension wants to support matrices (not sure if it's as an
> additional extension on top of V or as part of V proper).
>
>  if you can pseudo-code an example instruction, or load/store, that
> would be great.
>
an example from SPIR-V would be OpMatrixTimesMatrix, on p. 158 of
https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.pdf
I would have to refresh my memory on the exact order of operations in a
matrix multiplication in order to write pseudo-code.

Here's an implementation of 4x4 by 4x4 matrix multiply from the glm library
(almost-canonical math library for 3D graphics in C++):
https://github.com/g-truc/glm/blob/6f6f4d3ae8df98f0145a575f383e0387f03b8626/glm/detail/type_mat4x4.inl#L630

>
>  i did consider last night adding a "remap" option to the register
> file.  so whereas normally you do this:
>
>  VL=3
>
>  add r10, r20, r30
>
> =>
>
>  add r10, r20, r30
>  add r11, r21, r31
>  add r12, r22, r33
>
> it would be (assuming elwidth=8):
>
> for i in range(VL):
>    r10[i] = r11[i] + r12[i]
>

You would have to explain the semantics of r10[i] in more detail as I don't
know what you meant by that.

>
> for elwidth = 16 it would be obviously r10[i..i+1] = .....
>
> this could be set as a "mode" in the STATE.
>
> not sure what to do if VL*elwidth goes beyond XLEN?
>
> it *might* also solve the issues you were talking about for reordering
> structs of arrays to arrays of structs, jacob.
>

Jacob