<div dir="ltr"><div dir="ltr"><div dir="ltr">On Fri, Feb 1, 2019 at 1:19 AM Bruce Hoult <<a href="mailto:brucehoult@sifive.com">brucehoult@sifive.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Jan 31, 2019 at 11:53 PM Luke Kenneth Casson Leighton via<br>
llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> ---<br>
> crowd-funded eco-conscious hardware: <a href="https://www.crowdsupply.com/eoma68" rel="noreferrer" target="_blank">https://www.crowdsupply.com/eoma68</a><br>
><br>
> On Thu, Jan 31, 2019 at 10:22 PM Jacob Lifshay <<a href="mailto:programmerjake@gmail.com" target="_blank">programmerjake@gmail.com</a>> wrote:<br>
> ><br>
> > We're in-progress designing a RISC-V extension (<a href="http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-January/000433.html" rel="noreferrer" target="_blank">http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-January/000433.html</a>) that would have variable-length vectors of short vectors (1 to 4):<br>
> > <VL x <4 x float>><br>
> > where each predicate bit masks out a whole short vector. We're using this extension to vectorize graphics code where where variables in the pre-vectorization code are short vectors.<br>
> > So, vectorizing code like:<br>
> > for(int i = 0; i < 1000; i++)<br>
> > {<br>
> >     vec4 color = colors[i];<br>
> >     vec3 normal = normals[i];<br>
> >     color.rgb *= fmax(0.0, dot(normal, light_dir));<br>
> >     colors[i] = color;<br>
> > }<br>
> ><br>
> > I'm planning on passing already vectorized code into LLVM and using LLVM as a backend for optimization and JIT code generation.<br>
> ><br>
> > Do you think the EVL proposal would support an ISA like this as it's currently<br>
> > written (by pattern matching on predicate expansion and vector-length<br>
> > multiplication)?<br>
><br>
> whilst it may be tempting to suggest that a solution is to multiply up<br>
> the bits in the predicate (into groups of 3 or 4), the problem with<br>
> that is that if there are operations that require vec3 or vec4 as<br>
> operands interspersed with predicated operations that do not, that<br>
> realistically implies a need for two separate predicate registers,<br>
> otherwise cycles are wasted swapping predicates OR it implies that the<br>
> architecture *allows* two separate predicate registers to be selected.<br>
><br>
>  consequently, it would be much, much better to be able to have a<br>
> single bit of a predicate apply to the *entire* vec3 or vec4 type, on<br>
> each outer loop.<br>
<br>
This situation can be handled easily in the standard RISC-V vector<br>
extension. You'd do something like...<br>
<br>
vsetvli t0, a0, vsew128,vnreg8,vdiv4<br>
<br>
... to configure the vector unit to provide eight vector register<br>
variables divided into a standard element width of 128 bits (some<br>
instructions will widen or narrow one step to/from 64 bits or 256<br>
bits), and then dividing each 128 bit element into 4 parts.<br>
<br>
Arithmetic/logical/shift will happen on 32 bit elements, but<br>
predication and loads and stores (including strided or scatter/gather)<br>
will operate on 128 bit elements.<br>
<br>
[I just made up "vnreg8" as an alias for the standard "vlmul4" because<br>
"vlmul4,vdiv4" might look confusing. Either way it means to put 0b10<br>
into bits [1:0] of the vtype CSR specifying that the 32 vector<br>
registers should be ganged into 8 groups each 4x longer than standard<br>
because (I'm assuming) we need more than four vector registers in this<br>
loop, but no more than eight]<br></blockquote><div>Neat! I did not know that about the V extension. So this sounds as though the V extension would like support for <VL x <4 x float>>-style vectors as well.</div><div><br></div><div>We are currently thinking of defining the extension in terms of a 16-bit prefix that changes standard 32-bit instructions into vectorized 48-bit instructions, allowing most future or current standard/non-standard extensions to be vectorized, rather than having to wait for additional extensions to have vector versions added to the V extension (one reason we are not using the V extension instead), such as the B extension. Having a prefix rather than, or in addition to, a layout configuration register allows intermixing vector operations on different group/element sizes without having to constantly change the vector configuration every few instructions. We would also be reserving a 32-bit opcode for compressed variants of the most commonly used 48-bit prefixed instructions, similar in style to the C extension. Having a prefix also allows (assuming we don't run out of encoding space) larger register fields, we're planning on 128 integer and 128 fp registers.</div><div><br></div><div>Btw, for anyone interested, feel free to join us over on libre-riscv-dev or follow at <a href="https://www.crowdsupply.com/libre-risc-v/m-class">https://www.crowdsupply.com/libre-risc-v/m-class</a> (currently somewhat out-of-date).</div><div><br></div><div>Jacob</div></div></div></div>