[llvm-dev] [RFC] Matrix support (take 2)

[John McCall via llvm-dev]

On 5 Dec 2018, at 13:41, Adam Nemet wrote:
> -------------------------
> Proper padding for small matrices
> -------------------------
>
> We want the individual rows/columns (for row/column-major) to be 
> naturally aligned by no more than the max vector alignment.  E.g. for 
> a 3 x 3 x float with column major order, we should have a single 
> element padding after each column which is a total of 48 bytes.  For 
> option A, since it’s a new type we can just define this in the new 
> ABI.
>
> For option B and C, on the other hand, vector alignment and padding is 
> already mandated by the VectorType.  This is part of the ABI when 
> people use vector_size or ext_vector_type attributes on the clang 
> side.
>
> Alignment and allocation size (including padding) is the original size 
> of vector rounded up to the next power-of-2.  So for example a 3 x 3 x 
> float pad(1) or 12 x float is rounded up to 64 bytes.  This is 
> excessive.  I also need to support unpadded matrices that are 
> effectively ABI-compatible with arrays.
>
> Front-ends could lower to arrays instead of vectors and then cast them 
> to vectors specifying the proper alignment.  This would complicate 
> front-ends and the IR.  A more reasonable solution would be allow 
> reducing the alignment and in turn the padding of the vector type 
> itself.  We could have an align attribute on the type itself:
>
> For example <12 x float align(16)> for naturally aligned columns or <9 
> x float align(1)> for the unpadded case.
>
> In summary, option B and C can be made to work with some IR 
> extensions.

In general, IR type alignment is all but meaningless.  A well-behaved 
frontend should be setting an explicit alignment on every declaration, 
definition, allocation, and access it generates (if it's ABI, at least), 
and it must always lower aggregate types in a way that understands that 
IR type alignment can arbitrarily differ from the actual alignment of 
the frontend's original type.  So while I'm certainly supportive of 
allowing vector types to carry additional information besides just an 
element type and count, I'm a little skeptical specifically about the 
value of it carrying an alignment.

John.