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

[Chris Lattner via cfe-dev]

> On Oct 17, 2018, at 11:57 PM, Tim Shen <timshen at google.com> wrote:
> 
> On Tue, Oct 16, 2018, 11:12 Chris Lattner via cfe-dev <cfe-dev at lists.llvm.org <mailto: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.

Adam and I discussed this at the devmtg, and indeed his idea is to have a “codegen prepare” sort of pass that does some amount of pre-legalization of matrices (which should also be applicable to large vectors) with the goal of reducing register pressure etc.

Adam, can you please summarize the discussions you had and what you see as the next steps here?  Thanks!

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181023/72cda978/attachment.html>