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

I was thinking that we'd only use separate swizzle instructions. If we wanted,
they could be macro-op fused with preceding/succeeding ALU instructions.

> > 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.

Do note that we'd only need the 2 bits for another SUBVL field, not the 13/14
bits (12 for swizzle + SUBVL) for a whole swizzle immediate.

> > 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?

Both of using reserved encodings in SVP48/64 and inside VBLOCK

>  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".

it doesn't trigger because of being the right register, but because jumps
aren't valid inside VBLOCK. This requires VBLOCK encoding exactly which
instructions are inside and not (which I recall it doing).

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