[mlir][dxsa] Add bfi instruction

[hvdijk]

This commit generalises the DXSA_*Op to allow arbitrary numbers of arguments.

[hvdijk]

I'm not sure if TableGen gives us a better way to avoid having to spell out a separate class for every possible number of arguments. Does this approach look okay or should we do it differently?

[tagolog]

@asl could you take a look at the way the op is built here?

[tagolog]

@hvdijk, Thank you for the prototype. I would rather not land the generalized version of the DXSA_PlainOp. There are several reasons:

• Multi destination operations need semantic operand names and appropriate getter names:
  • sincos -> $sin, $cos, $operand
  • imul / umul -> $hi, $lo, $lhs, $rhs
  • udiv -> $quot, $rem, $lhs, $rhs
  • uaddc -> $sum, $carry, $lhs, $rhs
  • usubb -> $diff, $borrow, $lhs, $rhs
  • swapc -> $dst0, $dst1, $cond, $src0, $src1
    A generic DXSA_PlainOp gives getDst0()/getDst1()/getLhs()/getRhs() for all of them and loses the role. The only ways out are (a) more parametrisation by an explicit name list, or (b) keeping per-shape local classes anyway. We already do (b) for DXSA_SincosOp and DXSA_AtomicOp; it is 5-8 lines per shape.
• The chain of !foldl/!setdagarg/!interleave/!range is effectively unreadable once written: any mistake shows up as a generated-C++ error with no trail back to the TableGen expression that caused it.
• No MLIR dialect uses this idiom. SPIR-V, Arith, Math, MemRef, Vector, Affine, LLVM dialect, P4HIR, IREE VM all uses hand-written tablegen classes.
• About 225 operations (arithmetic, FP, bitwise, condition, conv, atomic) - Unary, Binary, Ternary gain nothing from generalisation. 13 operations with no operands can be covered with 5 lines of clear code - new DXSA_NoOperandOp operation (see [mlir][dxsa] Add control flow instructions #194). Multi destination arithmetic needing its own local class for semantic names - about 7 operations.