[Libre-soc-dev] Implicit setvli on blr?

[Luke Kenneth Casson Leighton]

On Mon, May 24, 2021 at 6:07 AM Jacob Lifshay <programmerjake at gmail.com>
wrote:

> On Sun, May 23, 2021, 22:01 Lauri Kasanen <cand at gmx.com> wrote:
>
> > Hi,
> >
> > Something that came up, since the spec is "return to normal openpower
> > mode on function return", is there an implicit setvli 1,1 on blr?
>

this is the rule for VBLOCK which is part of Draft 0.6 RISC-V SimpleV.
VBLOCK is not part of SVP64.


>
> Afaik no. what would happen is, whenever executing a branch instruction,
> the cpu would switch out of vblock and/or 16-bit decoding modes -- both of
> which aren't going to be implemented for now, so nothing special happens.
>

VBLOCK was part of the Draft 0.6 RISC-V SV.  16-bit SVP64 modes would
be unaffected (just another encoding), they have nothing to do with SVSTATE
or VBLOCK.

so, SVSTATE, which contains VL, MVL etc has to become "part of the
woodwork",
alongside MSR and PC
https://libre-soc.org/openpower/sv/sprs/
<https://libre-soc.org/openpower/sv/sprs/?>

as long as you have no intention of calling any functions from within SVP64
loops, you should be able to get away with the calling convention of
completely
ignoring SVSTATE and only setting it up at the start of the loop.

reason: if you don't use any SVP64 assembler, SVSTATE is quiescent.

if you start calling functions from within SVP64 loops, that's something
that
gets sufficiently complex that the majority of Cray-style Vector-related
compilers simply don't do it: the calling conventions alone are a pig to
define.

you *can* do it - however if you write a sub-function which critically
relies on a particular MVL, bear in mind that MVL is a static immediate
quantity, you'd better make absolutely sure that no callers call that
function *without* being *ABSOLUTELY* aware of that size, MVL.

why?

this should be obvious: MVL literally defines precisely and exactly the
maximum quantity of registers used by a loop.  exceed that quantity and
you *will* cause data corruption by over-running statically-allocated
compile-time register file numbering.

l.