[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 #54 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #52)

> Taking that in to account:
> 35.7% for the encodings proposed in comment #45
> 
> (I may have made a mistake in my calculations though)

no problem.  we just have to keep an eye on it.

> > I wonder instead if we can fit some bits into VBLOCK or SVP64.
> 
> Didn't check for VBLOCK, but I would be surprised if they won't fit in SVP64.

because i didn't realise the importance of swizzle, the 16 bits are entirely
taken up with extending rd/rs1-3 to 7 bits, and with setting VL and VLMAX.

it'll need a redesign, to fit, where one bit indicates "swizzle-mode".
even there, it's only going to be possible to fit either 8-bit or 12-bit.
certainly not 16-bit (twin swizzle).

> However, since swizzles are one of the few instruction types that require
> multiple non-trivial [1] SUBVL fields/values, I think having it encoded in
> the swizzle instruction itself [2] would be better.

Midgard has *two* swizzle immediates for the ALU side.  hypothetically,
one could go in the instruction, another in the SVP64 block.

> 1: I count instructions like load-gather/store-scatter as trivial, since all
> instruction arguments either use SUBVL (for src/dest reg) or SUBVL is always
> 1 (for address reg), so multiple SUBVL's don't need to be encoded
> 
> 2: includes the prefix if the prefix is always required
> 
> > 
> > If these ops are that common and that important, trying to cram everything
> > into OP32 is just asking for trouble.
> 
> They can go in other opcode blocks. We could do something such as share the
> opcode with JAL (for example) and [f]swizzle[i/2] would only be valid inside
> VBLOCK or prefixed, where JAL isn't valid anyway.

are you considering the idea of adding special opcodes into the "reserved"
encodings of SVP48/64?  or...

oh, wait, yes, i see: if vectorisation/predication/something-else is triggered
on a register being used by JAL (for example), it's taken to mean:

"JAL can't be vectorised, therefore you must mean swizzle".

where in SVP* that's easy to do (implicitly), but for VBLOCK we have to
be quite careful.  if the op does not have as many registers then the
"trigger" conditions might not activate, if the "shadowing" operation
needs a scalar reg where the "shadowed" op has a scalar.

JAL rs1 # scalar
SWIZZLE rs1 (scalar), rs2 (vector), rs3 (vector)

that's not going to work, because rs1 is a scalar, it won't trigger
the JAL to go "oh my rs1 is a vector they must have meant swizzle".

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