[llvm] [ARM][TableGen][MC] Change the ARM mnemonic operands to be optional for ASM parsing (PR #83436)

[Ivan Kosarev via llvm-commits]

================
@@ -1474,7 +1513,7 @@ void AsmMatcherInfo::buildOperandMatchInfo() {
         OperandMask |= maskTrailingOnes<unsigned>(NumOptionalOps + 1)
                        << (i - NumOptionalOps);
       }
-      if (Op.Class->IsOptional)
+      if (Op.Class->IsOptional && Op.Class->OptionalShouldOffsetCustomParsers)
----------------
kosarev wrote:

Is `vmoveq.f32 q2, #0.1` supposed to be parsed fine with this patch in place? Here I am at `da3d1607ae9a`, and it doesn't seem to work:

```
$ ./llvm-mc -mcpu=cortex-a8 -triple armv7-apple-darwin -debug <<< 'vmoveq.f32 q2, #0.1'
...
<stdin>:1:1: error: invalid instruction, any one of the following would fix this:
vmoveq.f32 q2, #0.1
^
<stdin>:1:16: note: operand must be a register in range [q0, q15]
vmoveq.f32 q2, #0.1
               ^
<stdin>:1:16: note: invalid operand for instruction
vmoveq.f32 q2, #0.1
               ^
```

The immediate still seems to fail to be parsed for `VMOVv4f32`, if that's the intended instruction:
```
Trying to match opcode VMOVv4f32
  Matching formal operand class MCK_CondCode against actual operand at index 1 (<ARMCC::eq>): match success using generic matcher
  Matching formal operand class MCK__DOT_f32 against actual operand at index 2 ('.f32'): match success using generic matcher
  Matching formal operand class MCK_QPR against actual operand at index 3 (<register q2>): match success using generic matcher
  Matching formal operand class MCK_FPImm against actual operand at index 4 (1036831949): operand match failed, recording near-miss with diag code 0
  Matching formal operand class InvalidMatchClass against actual operand at index 5: actual operand index out of range
```

> The way this is done is at operand parsing time (eg. `ARMAsmParser::parseOperand` in this case), where `MatchOperandParserImpl` uses the Mnemonic and the current OperandVector's size to determine if the operand at that index should use a custom ParserMethod.
> 
> This causes issues when an operand with a custom ParserMethod comes after an optional operand as then the index can change.

So how is this a problem, exactly? The `maskTrailingOnes()` call above is supposed to mark all positions at which an operand with a custom parser may appear, taking into account all optional operands that may precede it. Doesn't it do it correctly in your case for some reason?

> In this case before this change the parser for `nImmVMOVF32` (which has parser class `FPImmOperand`) was being applied to `q2` instead of `#0.1` because `${p}` was present in this case and the parser was assuming that it would not be present (the default behaviour previously).

Again, how you think is this wrong? In presence of optional operands, a custom parser being applied to an umatching operand is normal. Such a custom parser is supposed to return no-match, thus letting know the rest of the parsing infrastructure that this is an operand of some other kind and so other parsers should be tried.


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