[llvm-dev] [cfe-dev] RFC: First-class Matrix type

[Bruce Hoult via llvm-dev]

On Wed, Oct 17, 2018 at 11:57 PM, Tim Shen via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Tue, Oct 16, 2018, 11:12 Chris Lattner via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Adding a new dedicated first-class type has several advantages over
>> mapping them directly to existing IR types like vectors in the front end.
>> Matrices have the unique requirement that both rows and columns need to be
>> accessed efficiently.  By retaining the original type, we can analyze
>> entire chains of operations (after inlining) and determine the most
>> efficient *intermediate layout* for the matrix values between ABI
>> observable points (calls, memory operations).
>>
>>
>> I don’t understand this point at all.
>>
>
> I *think* what it says is that a matrix type like <4 x 4 x i32> can be
> designed in a way that it does not imply the data layout (row major, column
> major, etc), so that passes feel free to transpose the data into another
> layout if it's profitable.
>
> It also seems to say that there can be such a global analysis pass to
> assign one layout per use, then insert necessary transposes. Such pass
> tries to achieve a global maximum of performance.
>
> However, the argument seems to imply that a vector type like <16 x i32>
> can't do so. In the favor of option #1, I argue that the plain <16 x i32>
> enables the same optimization opportunities, as long as the uses are not on
> ABI boundaries.
>
>>
Given that, for example, a unit stride along a 2nd or 3rd axis will
translate into a constant stride when flattened into a 1D vector .. yes,
that is essentially an equally easy to recognise pattern.

The aim will always be to interchange loops so as to get unit stride in an
underlying 1D vector. Which can be done directly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181018/cd129a62/attachment-0001.html>