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

[Adam Nemet via llvm-dev]

> On Dec 5, 2018, at 8:46 PM, John McCall <jmccall at apple.com> wrote:
> 
> 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.  

Sure, that’s clear.  I may not have been precise above that I actually tried to lower the alignment in other ways but failed.

> 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.

I wasn’t able to lower the alignment (and alloc size) for alloca through the align attribute.  I assumed that it was meant to only allow increasing alignment.

I am also unclear how lowering the alignment should work for a vector data member of a structure type.  Would I have to make the structure packed and manually fill in the padding?  Is that desirable every time a flattened matrix is used inside a structure?

Thanks,
Adam

>  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.