[Libre-soc-isa] [Bug 553] svp64 register mapping to accomidate AltiVec vectors expanding fp registers

[bugzilla-daemon at libre-soc.org]

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

--- Comment #7 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #6)
> cloding as invalid. a future version of SVP64 on top of quad precision
> instructions (excluding all packed simd instructions) is more appropriate
> and is nothing to do with this invalid mapping concept.

it's still valid, because those quad-precision instructions are already defined
to use vsx registers. we will still want some kind of mapping because we want
the scalar 128-bit instructions to use the exact same registers as are used for
128-bit vector elements.

As currently defined, svp64 is critically incompatible due to register layout
with svp64 on top of the existing 128-bit scalar instructions, assuming svp64
uses contiguous element packing and doesn't skip high-64-bit-halves of the
128-bit fp registers that you get from existing 128-bit openpower scalar
instructions.

e.g.:
(f128 scalar add with svp64 vector prefix)
sv.xsaddqp vsr0.v, vsr32.v, vsr64.v with elwidth=128 uses:

+-----+-----+-----+-----+
|  f0 |  f1 |  f2 |  f3 | fp register number
+-----+-----+-----+-----+
| el0 | el1 | el2 | el3 | 64-bit high half of scalar
+-----+-----+-----+-----+
| el0 | el1 | el2 | el3 | 64-bit low half of scalar
+-----+-----+-----+-----+

(f64 add)
sv.fadd f0.v, f32.v, f64.v with elwidth=64 according to current svp64 uses
(wasting the high-half of the 128-bit registers, unless remapped):

+-----+-----+-----+-----+
|  f0 |  f1 |  f2 |  f3 | fp register number
+-----+-----+-----+-----+
| --- | --- | --- | --- | 64-bit high half of scalar
+-----+-----+-----+-----+
| el0 | el1 | el2 | el3 | 64-bit low half of scalar
+-----+-----+-----+-----+

wasting the high-half isn't acceptable imho because we'd need 2x as big of a
register file for the uncommon uses of f128 or 128-bit integers -- therefore
the high half should instead be some other 64-bit registers so svp64 can use it
for vectors of 8/16/32/64-bit elements -- aka. remapping.

I've proposed the high halves of f0-63 be f64-127.

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