[Libre-soc-isa] [Bug 1071] add parallel prefix sum remap mode

[bugzilla-daemon at libre-soc.org]

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

--- Comment #26 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #25)
> (In reply to Luke Kenneth Casson Leighton from bug #1155 comment #43)
> > not happening, i have said this before and it is inviolate and not
> > to be discussed further under this bugreport as it is firmly out of
> > scope. they can write directly to SVSHAPEs and take the consequences
> > after reading the spec's warnings.
> 
> by choosing to not allow dynamic size on svshape instructions 

READ WHAT I WROTE.

the consequences are too damaging on the hardware, making it impractical.


you are
> forcing parallel reduction to be much less powerful than RVV (RVV supports
> dynamic reduction sizes),

i don't care what RVV does, here. they do not have precise interrupt
guarantees as a hard requirement for a start.

> since computing the right values of VL from the
> length is complex enough that it really shouldn't be done by software (it
> would be maybe 10-20 instructions), 

then you should explain and illustrate that instead of saying
"it MUST be dynamic" with no justification or explanation, given that
you have no idea of how to properly think through the consequences.

svindex and svoffset already compute a 2nd dimension based on VL,
however it is done from immediates (not GPR Hazards).

> hardware can be substantially more
> efficient since computing the length is basically a sum of several
> simple-ish terms, where carry-save adders shine.

then when you have explained the problem, which i have no idea of its
scope, potential solutions can be investigated *without* catastrophically
damaging SV.

> Also, setvl reads from registers, if svshape reads from registers it behaves
> very similarly in how the sv-prefix loop expander could have to wait for the
> value to be computed, and you had no problems with setvl...

it's the one and only entrypoint, and as such is limited in Register
Hazards.

svshape has FIVE register hazards as outputs already. the absolute
last thing we need is to make that SIX, one of which is a GPR as input.
the consequences would be catastrophic on the Hazard Mamagement.

HARD NO means HARD NO, jacob.


so.

please describe *exactly* the algorithm, or illustrate it clearly,
so that i can assess it properly.

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