[llvm] [DecoderEmitter] Support for DecodeOrder and `resolve-conflicts-try-all` (PR #157948)

[Sergei Barannikov via llvm-commits]

s-barannikov wrote:

Here is an interesting decoding conflict (I replaced some '.' with a/d/m to give names to fields):
```
    111110110101....aaaadddd0000mmmm
    111110110101________11110000____  t2AUTG
    111110110101____1111____0000____  t2SMMUL
    111110110101____________0000____  t2SMMLA
```
`t2AUTG` can only match if `aaaa != 1111`, (otherwise it is `t2SMMUL`)
`t2SMMUL` can only match if `dddd != 1111`, (otherwise it is `t2AUTG`)
`t2SMMLA` can only match if `aaaa != 1111 && dddd != 1111` (otherwise it is either `t2SMMUL` or `t2AUTG`)

The 1111 is the encoding of PC register.
Now if we have `aaaa == 1111` or `dddd == 1111`, no matter which order we try, we will always successfully decode the first attempted instruction. The issue is that `rGPR` decoder accepts `1111` as a valid (SoftFail) bitpattern, even though `rGPR` class does *not* contain `PC`.

One could argue that it is wrong to accept 1111 for `rGPR`, but it is not wrong for other instructions -- they should indeed be decoded and marked as SoftFail.

What I'm trying to say is that "decoding order" will not always work and we need a more sophisticated solution.
I was thinking about adding a "decoder predicate" -- small function or inline code that can disambiguate encodings, but I couldn't figure out what that function/code should take as input.


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