[libre-riscv-dev] SV / RVV, marking a register as VL.

[lkcl .]

On Friday, August 30, 2019, Jacob Lifshay <programmerjake at gmail.com> wrote:

> On Thu, Aug 29, 2019, 04:09 lkcl . <luke.leighton at gmail.com> wrote:
>
>> (taking isadev off cc for this one)
>>
>> On Thursday, August 29, 2019, lkcl <luke.leighton at gmail.com> wrote:
>>
>> that would then allow the substituted-instruction to go directly into
>> > dependency-tracking *on the scalar register*, nipping in the bud the
>> need
>> > for special CSR-related dependency logic, and no longer requiring the
>> > sub-par "stall" solution, either.
>> >
>> >
>>  The "cache" idea where a CSRR is rewritten to a MV is the key
>> implementation piece of the puzzle that I think means we can go ahead with
>> sv.setvl being a pointer-to-a-register rather than a CSR.
>>
>> Any thoughts on this one, Jacob (to isadev and lrv), any objections, or do
>> you need time to think about it?
>>
> the cache idea sounds like it should work in HW as long as VLPTR is not
> rewritten too often.
>

Pretty much yeah.


>
> to disable, VLPTR can be set to point to x0.
>

Exactly.


>
> One concern I have is that implementing a register allocator (and probably
> the instruction scheduler too) where there is register indirection may
> require rewriting large portions of LLVM, hence why I had proposed
> SVPrefix, where all the instructions just had the literal register numbers
> and not like SVorig where the CSRs dynamically repointed the registers to
> other registers.
>

Remember that they don't have to. In the 8bit VBLOCK format they can't.
There is nothing stopping the compiler from setting the regs when using the
16 bit format to be one to one and onto [math terms.
https://en.m.wikipedia.org/wiki/Bijection,_injection_and_surjection i mean
bijective]

VL is not like the elements. It is definitely a special case. Yes some
context will be required, to say that for the duration of VLPTR being
nonzero one of the scalar regs is reserved as VL.


>
> I guess we can work around this for just VLPTR by always setting it to
> point to the same register, but that kinda defeats the purpose of not just
> using that register in the first place along with a VLENABLE csr.
>

Hard allocation of one scalar reg to VL penalises RVC either way,
unfortunately.

L.