<div class="gmail_quote"><div dir="ltr">On Tue, Oct 16, 2018, 11:12 Chris Lattner via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div dir="auto" style="word-wrap:break-word;line-break:after-white-space"><div><div>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 <b>intermediate layout</b> for the matrix values between ABI observable points (calls, memory operations).<br></div></div></div></div></div></blockquote><div><br></div><div>I don’t understand this point at all.</div></div></div></blockquote></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div>