[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