[Libre-soc-bugs] [Bug 713] PartitionedSignal enhancement to add partition-context-aware lengths

[bugzilla-daemon at libre-soc.org]

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

--- Comment #111 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #109)
> (In reply to Jacob Lifshay from comment #108)
>   but when added in "fixed" mode it should add five to the
>   *whole* length then recompute the Vector Lane widths
>   using the partition counts.  obviously here if the
>   programmer fails to take into account the partition
>   allocation some of the computed Vector Element widths
>   will not fit (XLEN=64 +3 will be 67 which is not
>   divisible by 8) but that is their problem to sort out

I'd argue strongly that we should specifically not do that, what we should do
instead is mirror how XLEN works in the OpenPower spec pseudo-code, where XLEN
+ 5 means that each per-vector-element instance ends up with types 5 bits
wider, so:

elwid=8: XLEN + 5 -> element width of 8 + 5 == 13
elwid=16: XLEN + 5 -> element width of 16 + 5 == 21
elwid=32: XLEN + 5 -> element width of 32 + 5 == 37
elwid=64: XLEN + 5 -> element width of 64 + 5 == 69

The above is the semantics I explicitly rely on in the pseudo-code for addg6s
(where it creates values with a width of XLEN + 4, because it needs 4 extra
bits to prevent the logic from overflowing), we should not make SimdSignal's
XLEN behave differently just because you like doing arithmetic on the full SIMD
width.

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