[libre-riscv-dev] [Bug 139] Add LD.X and ST.X? Strided

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=139

--- Comment #69 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #64)
> I worked out why Midgard has a dest mask and allows swizzle on both src
> operands: it allows FULL arbitrary ALU selection, covering all possible
> permutations of dest xyzw and src1 src2 xyzw.
> 
> The reason is that the dest needs only to know which elements are to be
> skipped ie the sequence is maintained, and *both* src element permutations
> may be reordered to match that sequence.
> 
> Also, again, no DESTSUBVL, that is implicit in the number of bits in the
> destmask and defines how many elements are copied from the two srces.
> 
> The swizzles in Midgard and the destmask are all immediates, not in regs
> (solving compiler error concerns), and the total number of bits is 8+8+4 =
> 20.
> 
> No wonder GPU ISAs are enormous.

They generally don't care about code size...

> 
> Well, apart from destmask, VBLOCK can handle this case. Or, destmask has to
> be specified as a full 8 bit swizzle, not a 4 bit predicate-like bitmask.
> 
> That deals with the ALUs, although it leaves SVP with a "hole" (no
> equivalent in SVP to VBLOCK swizzle capability, at the moment).

I would be surprised if we couldn't cram a simplified swizzle field (8 bits for
swizzle, 1-2 bits to allow specifying which src reg is swizzled) into SVP64, if
not we can always define a SVP80 format, though at that point it may be better
to just use macro-op fusion. :)

> 
> If we go with the MV.swizzle OP32 format that you designed, that gives a way
> to cut down on opcodes used, by reordering data once and be done with it. It
> does mean having copies of data, which uses up regs.
> 
> However if registers are ever under pressure, VBLOCK can be used to refer to
> the data in-place, just like in Midgard.

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