[Libre-soc-bugs] [Bug 558] gcc SV intrinsics concept

[bugzilla-daemon at libre-soc.org]

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

--- Comment #24 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Alexandre Oliva from comment #23)
> today's conversation about VL=0 got me thinking that VL is dynamic, which
> means the compiler may have to be able to mv from and to it.  a setvli insn
> that sets VL to MAXVL, or even to a different immediate, won't quite cut it.

there is a setvli which sets VL to an immediate.
there is also a setvl which sets VL to the minimum of a value read from a
register and an immediate (used for limiting VL to the space allocated by the
register allocator). both are unprivileged instructions and intended to be used
in user code.

> I think the compiler has to be able to represent it as something it can set
> from another register, say one previously loaded from it, so that it can
> operate on vectors of different dynamic lengths, at least if we wish to be
> able to expose fail-on-first (which is where vl becomes visible as a
> distinct quantity from maxvl, IIUC).
> 
> This means it may not be enough for setvli and some privileged
> register-restore for interrupts to be able to set vl from an immediate or
> from memory: the compiler has to be able to save it and restore it elsewhere.

I expect there to be a VL SPR that can be read using a single mfspr
instruction. setvl[i] is used for writing to VL, since it is VL = min(value,
MAXVL) where MAXVL is the immediate containing the number of vector elements
that the register allocator allocated space for.

> This even relates with calling conventions: are VLI and VL supposed to be
> preserved across function calls, so a function that uses them has to save
> the state and restore it before returning, or are the call-clobbered and
> it's up to the caller to preserve them?

I'm inclined to define two different ABIs where one has VL be clobbered by
calls and the other has it be saved by calls, though I'm not sure which should
be default.

There should also be a way to pass VL into a function as an argument through
the VL register and optionally have the caller expect the same VL to be set on
return, sorta like how structure return pointers are treated.

We may specify that VL must also be passed in r3 or something, but I don't know
that that's necessary.

> Having the vector state represented as a call-preserved register (set) would
> even enable the (userland) exception handling machinery to restore the
> register while unwinding the stack.

I'd expect VL to usually need to be reloaded or just be unused after a
stack-unwind anyway since that usually causes code to do completely different
stuff like error handling or terminating, so either way would work here -- we
just pick whichever is consistent with the default ABI.

> Though having it preserved by the caller might also make a lot of sense,
> since the caller might not even have to save it, and instead just know how
> to set it back up.

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