fence.tso should have a separate file for it.

Probably so. It'll make a bit of a mess because you'll need to exclude the specific FENCE.TSO encoding from the FENCE encoding.

Agree. In terms of encoding, this is captured by the hints key (I might not have that in main yet; it's used by the ISS decoder). Maybe there is a better key name?

fence.yaml:

# ...
hints:
  - { $ref: "inst/I/fence.tso.yaml" }
# ...

fence.tso.yaml:

# full fence.tso instruction

I can't comprehend why to encode fence.tso as hint. Do they need to be connected at all? I think FENCE is described in the ISA both as a category of intructions (everything related to FENCEs) and as just an instruction FENCE.

I think it kind of acts the same way as the funct3/funct7 fields for Register-Register operations

Can't we remove the fm field from fence as a variable field and just describe it as 0000 for FENCE and 0001 for FENCE.TSO or would that have any further implications?

How do we represent "reserved" values for which there is a "shall" in the ISA spec:

Likewise, many _fm_ [...] settings [...] are also reserved for future use. Base implementations shall treat all such reserved configurations as normal fences with fm=0000

Can't we remove the fm field from fence as a variable field and just describe it as 0000 for FENCE and 0001 for FENCE.TSO or would that have any further implications?

That's actually what the Sail code does:

mapping clause encdec = FENCE(pred, succ)
  <-> 0b0000 @ pred @ succ @ 0b00000 @ 0b000 @ 0b00000 @ 0b0001111
[...]
mapping clause encdec = FENCE_TSO(pred, succ)
  <-> 0b1000 @ pred @ succ @ 0b00000 @ 0b000 @ 0b00000 @ 0b0001111

I note that you used 0001, when the spec defines FENCE.TSO with fm=0b1000, but then I noticed that the IDL does the same (0001):

  if (fm == 1) {
    if (pred == 0x3 && succ == 0x3) {
      # this is a fence.tso instruction
      is_fence_tso = true;
    }
  }

Is the IDL code incorrect there? If we force FENCE to have fm=0b0000, then all the tests for values of fm go away?

LLVM also represents fm as a hardcoded value. I re-opened my issue on the ISA manual to see if I can get clarification on this (riscv/riscv-isa-manual#1782 (comment))

I was wrong and I think you caught an IDL error. Indeed, correct value is described in the ISA as fm=0b1000

Yep, that's an IDL bug.