<div dir="ltr"><div>Hi,</div><div><br></div><div>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.</div><div><br></div><div>These are the MVT's that we have added:</div><div><br></div><div>16x16 element (2D SIMD) 1-bit predicate registers:</div><div>v256i1</div><div><br></div><div>16x16 element (2D SIMD) 16-bit registers:</div><div>v256i16</div><div><br></div><div>20x20 element (2D SIMD) 16-bit registers: (we round up to v512 instead of v400):</div><div>v512i16</div><div><br></div><div>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)</div><div>v256i32</div><div>v512i32<br></div><div><br></div><div><br></div><div>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="color:rgb(17,17,17);font-family:Arial,sans-serif;font-size:13px"><a href="http://a.co/et2K1xk">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></div><div><br></div><div>-- Sean Silva</div></div>