[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 #29 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(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.

correct.  see
https://libre-soc.org/openpower/sv/setvl/

you will see that taking in a register RA 
 is possible, as is getting a copy out of VL, in RT.

> 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.

the complexity involved is so great that absolutely nobody has tried this.

they simply set the rule, "no function calls allowed except static inline (or
scalar ones that do not *in any way* touch vector state).


> 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?

no.  generally the rule is: function calls are simply prohibited.

> 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.

...  interesting.  i mean, this is theoretically possible: SVSTATE is after all
a user-accessible SPR.

however please understand that exceptions, even userland ones, *have* to switch
to an alternative SPR for SVSTATE.

it should be clear that allowing any exception to have the Sub-PC set to some
arbitrary value at the beginning of the trap is an absolute 100% guaranteed way
to get data corruption.


> 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.

honestly this is an entire area of active research that has not been solved,
merely avoided entirely by setting some strict rules (no extern function calls
allowed)

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