1. Messages
  2. Fractional LMUL Constraint

Re: Fractional LMUL Constraint

Robin Kruppe <hanna.kruppe@...>
 



On Sat, 21 Mar 2020 at 20:46, Bill Huffman <huffman@...> wrote:

Maybe this has been stated already, and I just haven't seen it, but it seems like there's a constraint with fractional LMUL that wasn't there before.  The compiler must ensure that: LMUL >= SEW/ELEN.

I agree, this is a useful and acceptable constraint. I proposed it in a different but equivalent formulation (SEW <= ELEN / n when LMUL = 1/n) in response to a previous fractional LMUL proposal by David Horner (<https://github.com/riscv/riscv-v-spec/issues/382#issuecomment-591564361>).

Best,
Hanna

I think that my concerns for lane crossing with fractional LMUL came from mentally violating this constraint without realizing its significance.

     Bill

In more detail, a number of constraints, and their origins must be:

  1. VLEN >= ELEN                          from the spec
  2. VLMAX = LMUL*VLEN/SEW   from the spec
  3. VLMAX >= 1                             seems obvious
  4. LMUL*VLEN/SEW >= 1           from #2 and #3
  5. LMUL >= SEW/VLEN               from #4
  6. LMUL >= SEW/ELEN               if we are not to increase minimum VLEN in #1 

#6 is put into compiler visible terms (without VLEN or VLMAX).  It is a new constraint, I think, since always before LMUL >= 1 meant it was forced to be satisfied because of the existing constraint that ELEN >= SEW.

Not only is it a constraint, but violating it would bring no advantage.  The computation would use registers just as efficiently with a larger LMUL.  For example, if there were only ELEN/2 and ELEN elements and widening/narrowing operations between them, LMUL < 1/2 would not reduce the number of registers used, but would reduce VLMAX for longer vectors without providing any advantage for shorter vectors.
Join tech-vector-ext@lists.riscv.org to automatically receive all group messages.