<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 16, 2018 at 11:13 PM, Martin J. O'Riordan <span dir="ltr"><<a href="mailto:MartinO@theheart.ie" target="_blank">MartinO@theheart.ie</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-IE" link="blue" vlink="purple"><div class="m_8022351284452693934WordSection1"><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634">Hi Sean,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634">I had to add ‘</span><span style="font-family:"Courier New";color:black">v16f16</span><span style="font-family:"Book Antiqua",serif;color:#943634">’ to our out-of-tree target, and this was to primarily to allow me to express lowering for all the OpenCL types (well, except for the ‘</span><span style="font-family:"Courier New";color:black">v3T</span><span style="font-family:"Book Antiqua",serif;color:#943634">’ types).<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634">The trend does seem to be towards larger bit-width SIMD registers, and as you say this will increase in time; but perhaps instead of using a discrete enumeration combined with additional entries in several switch-statements, it might be better to rethink MVTs using templates so that they can be instanced automatically as needed by a target.  That might be one way of avoiding the problem of having either a sparse population of MVTs as needed by the sum of all in-tree targets, an on the other-hand the bloat of expressing all possible combinations.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634">How does LLVM handle 2D vectors/matrices?</span></p></div></div></blockquote><div><br></div><div>We just use sufficiently wide 1D types. LLVM doesn't need to know anything about the 2D nature of the underlying SIMD. It is only visible via a restricted set of operations that we have intrinsics for.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-IE" link="blue" vlink="purple"><div class="m_8022351284452693934WordSection1"><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634">  I haven’t moved on to v6.0.0 yet, but so far as I can tell v5.0.x only abstracts 1D vectors: N-elements of M-bits, and having types like ‘</span><span style="font-family:"Courier New";color:black">v256i16</span><span style="font-family:"Book Antiqua",serif;color:#943634">’ is not quite the same as having support for let’s say ‘</span><span style="font-family:"Courier New";color:black">v16x16i16</span><span style="font-family:"Book Antiqua",serif;color:#943634">’.  Having a high-level abstraction for reasoning about NxN-elements of M-bits would be really useful/cool, especially for exotic instructions with special register allocation requirements, and for classic nested loops such as convolutions.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634">            MartinO<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634"><u></u> <u></u></span></p><p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@<wbr>lists.llvm.org</a>] <b>On Behalf Of </b>Sean Silva via llvm-dev<br><b>Sent:</b> 17 January 2018 02:58<br><b>To:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br><b>Subject:</b> [llvm-dev] Does it make sense to upstream some MVT's?<u></u><u></u></span></p><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">Hi,<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Our backend for Pixel Visual Core uses some MVT's that aren't upstream. Does it make sense to upstream them? I figure that as architectures get wider, we'll eventually have "all" possible combinations of widths and types, but on the other hand having code that isn't used by current backends in tree isn't great.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">These are the MVT's that we have added:<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">16x16 element (2D SIMD) 1-bit predicate registers:<u></u><u></u></p></div><div><p class="MsoNormal">v256i1<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">16x16 element (2D SIMD) 16-bit registers:<u></u><u></u></p></div><div><p class="MsoNormal">v256i16<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">20x20 element (2D SIMD) 16-bit registers: (we round up to v512 instead of v400):<u></u><u></u></p></div><div><p class="MsoNormal">v512i16<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">32-bit versions of the above 16-bit registers (to represent 32-bit accumulators for MAD instructions and also dual-issue "wide" instructions to the dual non-MAD ALU's in each lane)<u></u><u></u></p></div><div><p class="MsoNormal">v256i32<u></u><u></u></p></div><div><p class="MsoNormal">v512i32<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">For those interested in more details about Pixel Visual Core, the 6th edition of Hennessy and Patterson's "Computer Architecture: A Quantitative Approach" <span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#111111"><a href="http://a.co/et2K1xk" target="_blank">http://a.co/et2K1xk</a> has a section about it (Section 7.7 pg 579-592). I'll bring my copy to the next Bay Area LLVM Social if folks want to take a look.</span><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">-- Sean Silva<u></u><u></u></p></div></div></div></div></div></div></blockquote></div><br></div></div>