Investigation of TableGen freezes for some Core-V instructions

Affected Instructions

CV_MACUN (16 x 16 bit multiply + 32bit acc + right shift) -> 33 bit intermediate result
CV_MULURN (16 x 16 bit multiply + add(1 << (n-1))) + right shift) -> 33 bit intermediate result
CV_MULSRN -> 33 bit intermediate result
CV_MACHHSN -> 33 bit intermediate result
CV_MULHHURN -> 33 bit intermediate result
CV_MACHHUN -> 33 bit intermediate result
CV_MACSN -> 33 bit intermediate result
CV_MULHHSRN -> 33 bit intermediate result
CV_MACHHSRN -> 34 bit intermediate result
CV_MACSRN > 34 bit intermediate result
Most dot products…

CV_ADDN (32 x 32 bit addition + trunc to 32 bits + right shift) -> 32 bit intermediate result
...

Observations:

There is a mismatch between MUL and ALU in RTL of CV32E40P (MUL has 2 carry bits, while ALU just overflows)
Core-V LLVM compiler uses truncating patterns for MAC/MUL
CoreDSL (used as Seal5 input) reflects the behavior of the RTL; hence CV_ADDN is not affected by the freeze.
Needs more experiments

Currently we just filter out the broken instructions completely: https://github.com/tum-ei-eda/seal5/blob/848e2ba72cd97302655aa006ce4faaa64b3c4098/examples/cfg/xcorev/filter.yml#L24 (Skipping just the pattern gen would also work)
Adding explicit truncations to the CDSL heavior of the affected instructions would also help, but we would not match the RTL then...

[ ] Test on newest version of LLVM
[ ] Build minimal example to reproduce bug (MACUN? ADDN with carry?  Map to pseudo instr to drop dependency on Core-V LLVM)
[ ] Find the reason for the freeze (endless loop?)
[ ] Report bug to LLVM community
[ ] Submit bugfix