[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 #23 from Alexandre Oliva <oliva at libre-soc.org> ---
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.

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.

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?

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.

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.