[llvm] [DecoderEmitter] Support for DecodeOrder and `resolve-conflicts-try-all` (PR #157948)
    Rahul Joshi via llvm-commits 
    llvm-commits at lists.llvm.org
       
    Wed Sep 17 09:57:03 PDT 2025
    
    
  
jurahul wrote:
Following up on the 3rd call, what it seems to do is find the first instruction with some know-but-undecoded bit pattern and make a filter out of it. That means that one (or 2) instructions will become filtered-IDs and the remaining (2 or 1) will become VariableIDs. This new heuristic is somewhat similar, except that it looks at things from the opposite angle, i.e, extracts the least specific one. Also, currently if there is > 1 of these insts with `AllUnfilteredUnknown` they are attempted one-by-one, which does not happen in the `VariableIDs` case. So I am thinking they are slightly different. 
Here's an example of the conflict seen if I remove the 3rd call:
```
   ................
    0100............
    01000...........
    01000100........
    01000100........
    01000100_1101___  tADDrSP
    010001001____101  tADDspr
```
Basically, since for each unfiltered bit, either its unknown in one of the other, that is, there is no clear "winner" or "loser" in terms of being more or less assertive in the known bits. OTOH, in the cases the new heuristic handles, the instruction with all unfiltered bits unknown is clearly the least assertive. 
LMK if that makes sense and you agree with this direction. I'll then cleanup this code a bit (or maybe I'll wait for you other refactor to go in).
https://github.com/llvm/llvm-project/pull/157948
    
    
More information about the llvm-commits
mailing list