[PATCH] ppc/svp64: support svshape2 instruction

[Dmitry Selyutin]

On Thu, Sep 8, 2022 at 9:26 PM Dmitry Selyutin <ghostmansd@gmail.com> wrote:
> +   * 0b1000 and 0b1001 values are reserved for svshape2.
> +  { 0xf, 7, insert_SVrm, extract_SVrm, 0 },
>  const unsigned int num_powerpc_operands = (sizeof (powerpc_operands)
> @@ -4759,6 +4824,13 @@ const unsigned int num_powerpc_operands = (sizeof (powerpc_operands)
>     | (((uint64_t)(xop)) & 0x3f))
>  #define SVM_MASK       SVM (0x3f, 0x3f)
>
> +/* An SVM2 form instruction. */
> +#define SVM2(op, xop)                          \
> +  (OP (op)                                     \
> +   | (((((uint64_t)(xop)) >> 6) & 0x7) << 8)   \
> +   | (((uint64_t)(xop)) & 0x3f))
> +#define SVM2_MASK      SVM2 (0x3f, 0x1ff)
>
> +{"svshape2",   SVM2(22,281),   SVM2_MASK,      SVP64,  PPCVLE, {SVo, yx10, rmm, SVd, sk, mm}},
>  {"svshape",    SVM(22,25),     SVM_MASK,       SVP64,  PPCVLE, {SVxd, SVyd, SVzd, SVrm, vf}},

This is a tricky part. svshape2 shares some of its bits with svshape;
we reserve 0b1000 and 0b1001 values from svshape for svshape2.
I didn't find a clear way to express it other than custom callback and
powerpc_opcodes insertion order.
The order is significant; if svshape2 ends up after svshape, things
break, due to the fact that svshape opcode starts performing a loose
match.
Any ideas on how to refactor or improve it are more than desired.

-- 
Best regards,
Dmitry Selyutin