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

[Sergei Barannikov via llvm-commits]

s-barannikov wrote:

> I am under the (maybe mistaken) impression that the target is responsible that for a given bit pattern and features, only a single decoding succeeds for a given bit pattern, because that's what happens on the actual HW (each bit pattern has a deterministic interpretation). So an "O0" decoder can be built by essentially segregating each instruction into its own namespace, building N decoder tables and iterating through them till one succeeds (similar to resolve-conflicts-try-all). And in such a scenario, exactly one succeeds or none (i.e., return MCDisassembler::Success or SoftFail) and that's the final result of decoding. And then what we do on top of this O0 is a CSE/commoning of checks across these N instructions. In that case, the result should be independent of the decode order attempted. But maybe we are not there yet.

I totally agree. The reality, however, is imperfect. For example, when I tried to hoist predicate check before singleton field checks, AArch64 tests started to fail. This is because the predicated encoding was more specific than the unpredicated one, and early predicate check failure made the decoder choose the second encoding. The expected behavior is to choose the first one, fail the predicate check, and report an invalid encoding.

This is my greatest concern. Any big steps in the direction of improving conflict resolution will inevitably lead to change in the check/decode order that most, if not all, targets rely on (consciously or not).

I would suggest doing small steps instead. For instance, start by removing the third call to findBestFilter and develop a simple solution that fixes ARM/SystemZ conflicts (there are few).


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