[mlir][dxsa] Add control flow instructions

[tagolog]

• break
• continue
• default
• else
• endif
• endloop
• endswitch
• loop
• ret

Example:

  dxsa.break
  dxsa.continue
  dxsa.default
  dxsa.else
  dxsa.endif
  dxsa.endloop
  dxsa.endswitch
  dxsa.loop
  dxsa.ret

[hvdijk]

I suppose there is an open question here: do we want structured MLIR? If we do, we wouldn't model e.g. dxsa.endif as an instruction, we'd instead give dxsa.if a block and make the dxsa.endif implicit?

[asl]

I suppose there is an open question here: do we want structured MLIR?

No. This is a bytecode dialect.

[hvdijk]

This name is inconsistent with the above description and below classes. It's used in this PR for ops without inline operands, when the above description says "ops with inline operands". UnaryOp means one source operand, one destination operand. BinaryOp means two source operands, one destination operand. TernaryOp means three source operands, one destination operand. NullaryOp, by extension, would mean zero source operands, one destination operand. But that means it isn't suitable for the instructions you're defining in this PR.

If we merge #201 first, we can avoid the need to create a NullaryOp by making a slight tweak to it to modify PlainOp to make $precise optional, and use PlainOp<"...", 0, 0, 0> or such.

[dzhidzhoev]

If we merge #201 first, we can avoid the need to create a NullaryOp by making a slight tweak to it to modify PlainOp to make $precise optional, and use PlainOp<"...", 0, 0, 0> or such.

As it turns out, we have many zero-argument instructions.
I think it will be still useful to have a synonym for PlainOp<..., 0, 0, 0> for declaring such instructions (in case we decide to replace PlainOp<..., 0, 0, 0> with something else, for some reason). Would it be ok to call it DXSA_ZeroOperandOp, as an alternative for DXSA_NullaryOp or DXSA_ZeroOp?

[hvdijk]

Would it be ok to call it DXSA_ZeroOperandOp, as an alternative for DXSA_NullaryOp or DXSA_ZeroOp?

I think it still wouldn't belong here based on "ops with inline operands", but I'm now thinking it may be better to just update that description.

Looking at other instructions not yet covered, we also have instructions with source operands but no destination operands (mostly in #160, which needs updating). How would you feel about DXSA_NullaryOp<string mnemonic, int dsts = 1, bit hasprecise = 1> : DXSA_PlainOp<mnemonic, dsts, 0, hasprecise>;, and likewise for DXSA_UnaryOp, DXSA_BinaryOp, DXSA_TernaryOp ? That way, we can use DXSA_NullaryOp<"break", 0>, DXSA_UnaryOp<"breakc", 0>, etc. ?

[hvdijk]

As discussed in the call I created a branch to show what this would look like with the approach from #201 (slightly different from what is currently in #201, which I will update), 347ef62