search for: v256i16

...;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. These are the MVT's that we have added: 16x16 element (2D SIMD) 1-bit predicate registers: v256i1 16x16 element (2D SIMD) 16-bit registers: v256i16 20x20 element (2D SIMD) 16-bit registers: (we round up to v512 instead of v400): v512i16 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) v256i32 v512i...

...needed by the sum of all in-tree targets, an on the other-hand the bloat of expressing all possible combinations. How does LLVM handle 2D vectors/matrices? 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 ‘v256i16’ is not quite the same as having support for let’s say ‘v16x16i16’. 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 convolu...

...thing about the 2D nature of the underlying SIMD. It is only visible via a restricted set of operations that we have intrinsics for. -- Sean Silva > 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 ‘v256i16’ > is not quite the same as having support for let’s say ‘v16x16i16’. > 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 lo...