[llvm] [TableGen][Decoder] Decode operands with zero width or all bits known (PR #156358)

[James Nagurne via llvm-commits]

DragonDisciple wrote:

Hi @s-barannikov 

Our team maintains a downstream target that's running into an interesting issue with this commit. We had plenty of "hacks" for implicit operands, and those were relatively straightforward to update.

However, our decoder is now acting weirdly for a very specific construct:
- Operand is part of the "ins" dag for an instruction
- Operand is encoded in n bits
- Operand value is known statically to be all-zeroes

Something like:

```
def instr: Instruction<..., (outs), (ins OpTy:$op), ...> {
  bits<2> op = 0b00;
  let Instr{1-0} = op;
}
```

The decoder does not do anything that seems reasonable. Incoming to emitBinaryParser, we have:
- OpInfo.Fields.empty() == true, which I believe is weird. Isn't there a field that spans bits 1 and 0?
- OpInfo.InitValue.has_value() == true

This qualifies for a "fully defined operand", but does not trigger "UseInsertBits". Since there are no fields , the 'tmp' used to hold the decoded value for the field is never initialized. In the generated disassembler tables:
```
case 1:
    // NOTE: tmp is uninitialized
    if (!Check(S, DecodeOpTy(MI, tmp, Address, Decoder))) { return MCDisassembler::Fail; }
    return S;
```

So which would you surmise is the issue?:
- OpInfo.Fields should not be empty for 'op'
- There should be a check for OpInfo.Fields being empty but having InitValue.has_value() to ensure tmp is initialized

https://github.com/llvm/llvm-project/pull/156358