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

[John McCall via llvm-dev]

On 6 Dec 2018, at 1:24, Adam Nemet wrote:

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

Oh, I see, this is meant to avoid the rounding-up of the alloc size; 
somehow I missed that part of your post.  Yes, it makes sense that you 
need to be able to specify that.

> I assumed that it was meant to only allow increasing alignment.

Are you talking about the Clang attribute?  Yes, IIRC, that attribute is 
defined as not lowering alignment unless it's combined with packed.

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

That's what Clang does when the IR type for a field is aligned such that 
it would end up at the wrong offset, yes.

John.