[llvm] [DecoderEmitter] Support for DecodeOrder and `resolve-conflicts-try-all` (PR #157948)
Rahul Joshi via llvm-commits
llvm-commits at lists.llvm.org
Tue Sep 16 06:14:34 PDT 2025
================
@@ -1598,6 +1726,19 @@ void FilterChooser::doFilter() {
return;
}
+ // If we were unable to find a useful filter and there are multiple decode
+ // orders involved, split the candidates by decode order and create per decode
+ // order choosers.
+ if (hasMultipleDecodeOrders()) {
----------------
jurahul wrote:
ok. Taking a step back, I looked into what hasCompleteDecoder means in the decoder emitter, hasCompleteDecoder seems to set DecodeComplete = false whenever `decodeToMCInst` return Fail. So the condition (DecodeComplete == true and S != Fail) will never happen (except in the `bits<0>` case, which might be an oversight?). So, we really do not need 2 outputs from `decodeToMCInst` (S and DecodeComplete). That's one NFC simplification that can be implemented.
Next, I agree that in my downstream cases, encodings that have the same static bit pattern but encode different register classes in the variable portion need to be marked with hasCompleteDecoder = 0. This correctly indicates the fact that even if we match all the statically know bits, there are > 1 encoding that can match, so they need to have hasCompleteDecoder = 0.
Now just doing that does not resolve the conflict, in that, I still get the decoding conflict. To address that, it seems we need to handle the case where in a filter all remaining IDs are variable IDs and there are no filtered IDs. Or something like that. Maybe I'll first implement the NFC change above to drop the `DecodeComplete` output and then go from there.
https://github.com/llvm/llvm-project/pull/157948
More information about the llvm-commits
mailing list