[Libre-soc-isa] [Bug 535] setvl/setvli encoding & future reg file expansion

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=535

--- Comment #7 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #6)
> (In reply to Jacob Lifshay from comment #5)
> > I would expect that the final encoding efficiently support the 2 most common
> > usecases:
> > 1. set VL to a constant
> > mvl = immed1
> > vl = immed1
> > 
> > 2. set VL to a variable
> > mvl = immed1
> > vl = min(RA, mvl)
> > RT = vl
> > 
> > We don't generally need the option to not set mvl or not set vl, since
> > that's only relevant in very obscure usecases (can't think of any at the
> > moment). 
> 
> setting VL but not MVL is needed to not disrupt a previously-set MVL
> 
> setting MVL but not VL is needed likewise to not disrupt (except by
> truncation VL=min(VL, MVL)) a previously-set VL.

Yes, but practically speaking, what's the usecase for setting VL or MVL
separately from each other? The compiler knows MVL's constant value since it
did register allocation, so can just supply it to all setvl[i] instructions. no
mvl spr needed.

> > I'm assuming you can just use a mfspr to read vl.
> 
> by wasting one extra instruction, by that instruction being a 100%
> unavoidable mandatory part of absolutely all and any loops...

did you notice that setvl writes to an output register?

> ... yes.
> 
> [translation: not a good idea]
> 
> > Honestly, if vl
> > can only be set using setvl[i], we can just get rid of mvl entirely, 

I should clarify, I only meant removing the mvl register, not the mvl immediate
field or the calculation using mvl.

> > mtspr could be entirely equivalent to `setvl 0, ra, 64` or just not
> > supported (always traps no matter privilege mode) for writing VL.
> 
> no, use of mtspr is definitely not equivalent because that cuts out the
> setting of RT.

I didn't say mtspr was equivalent to all setvl instructions, just that specific
one which opts out of writing RT by setting the register field to 0.

> the thing is that setvl/i is actually quite complex.  it took me several
> weeks to understand it fully in RVV, and then even longer to realise and
> accept that the capabilities of RVV setvl were needed (in full)... *and in
> addition* the ability to set MVL at the same time was required.
> 
> the critical, critical part of setvl is this:
> 
>      RT = VL = min(min(VL, MAXVL), RA)

yup, that's completely retained. what isn't needed is keeping the maxvl value
around in a spr for later, since the compiler knows its value as a compile-time
constant (it has to since it allocated the registers) and can just put maxvl in
the immediate of all relevant setvl[i] instructions.

We can even include setting CR0 (if Rc = 1) to allow jumps on VL == 0
immediately after setvl.

For setvli, since the value VL is set to is a constant, having a destination
register is much less important.

> if all those calculations are not included then SV is severely penalised
> because it requires, at the bare minimum, two to three mandatory
> *additional* instructions (in an inner loop!) and at least one other as
> fixed overhead (outside the loop) just to achieve the same effect.
> 
> 
> suggestions to only use mtspr, mfspr, cut out mvl as an immediate are
> absolutely guaranteed to destroy the value of SV as an efficient
> instruction-compact Vectorisation system, or in the case of cutting out mvl
> destroy it entirely.

yup, hence why that's not what I'm proposing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.