IDL compiler hangs with long chained ORs

[syedowaisalishah]

While working on the Pr #607 scountovf.layout generation, I encountered a failure in the IDL compiler when processing code that included multiple nested when statements along with some unexpected characters (likely artifacts).
After cleaning the when statements and removing the unexpected characters, the issue no longer occurred, and all tests passed.
However, the compiler's inability to handle the original code gracefully may point to a parsing or robustness issue worth investigating.

Steps to Reproduce:

• Include deeply nested when statements in the layout.
• Use code with artifacts or special/unexpected characters.
• Attempt to compile using the IDL compiler.
• Observe the failure or crash.

Expected Behavior:
The compiler should either:
Handle the malformed input gracefully, or Fail with a clear and informative error message indicating the problem.

Actual Behavior:
The test fails without any clear indication of the root cause. Once the problematic lines are cleaned or restructured, the failure disappears.

Additional Notes:
The exact lines causing the issue were:

when (...) { ... }

[ThinkOpenly]

My view of the issues seen in the development of #607 is different.

The first indication of the problem was CI test failures. The symptom was that these few (3, IIRC) did not complete after hours of running and would be terminated. I was able to narrow these tests down to a single local test:

./do test:idl CFG=rv32

In the failure scenario, the test would get stuck "Type checking" CSRs:

Using devcontainer environment
Running with 1 job(s)
Parsing IDL code for rv32...mkdir -p /workspace/riscv-unified-db/.stamps
/workspace/riscv-unified-db/.home/.venv/bin/python3 lib/yaml_resolver.py merge arch /does/not/exist gen/arch/rv32
Merging arch: 100%|#################################################################################| 1680/1680 [00:00<00:00, 20620.96it/s]
[INFO] Merged architecture files written to gen/arch/rv32
/workspace/riscv-unified-db/.home/.venv/bin/python3 lib/yaml_resolver.py resolve gen/arch/rv32 gen/resolved_arch/rv32
Resolving arch: 100%|#################################################################################| 1680/1680 [00:10<00:00, 153.09it/s]
[INFO] Resolved architecture files written to gen/resolved_arch/rv32
done
Type checking IDL code for rv32...
[INFO] 2025-06-03 14:21:42: Allocating more SymbolTables                                                                                  |
Instructions: |===========================================================================================================================|
CSRs: |==============================================

I was able to narrow that down to a single commit, then further narrow it down to the IDL within a sw_read() attribute which included the following code:

  Bits<32> value =
    (CSR[mhpmevent3].OF << 3) |
    (CSR[mhpmevent4].OF << 4) |
    (CSR[mhpmevent5].OF << 5) |
    (CSR[mhpmevent6].OF << 6) |
    (CSR[mhpmevent7].OF << 7) |
    (CSR[mhpmevent8].OF << 8) |
    (CSR[mhpmevent9].OF << 9) |
    (CSR[mhpmevent10].OF << 10) |
    (CSR[mhpmevent11].OF << 11) |
    (CSR[mhpmevent12].OF << 12) |
    (CSR[mhpmevent13].OF << 13) |
    (CSR[mhpmevent14].OF << 14) |
    (CSR[mhpmevent15].OF << 15) |
    (CSR[mhpmevent16].OF << 16) |
    (CSR[mhpmevent17].OF << 17) |
    (CSR[mhpmevent18].OF << 18) |
    (CSR[mhpmevent19].OF << 19) |
    (CSR[mhpmevent20].OF << 20) |
    (CSR[mhpmevent21].OF << 21) |
    (CSR[mhpmevent22].OF << 22) |
    (CSR[mhpmevent23].OF << 23) |
    (CSR[mhpmevent24].OF << 24) |
    (CSR[mhpmevent25].OF << 25) |
    (CSR[mhpmevent26].OF << 26) |
    (CSR[mhpmevent27].OF << 27) |
    (CSR[mhpmevent28].OF << 28) |
    (CSR[mhpmevent29].OF << 29) |
    (CSR[mhpmevent30].OF << 30) |
    (CSR[mhpmevent31].OF << 31) |
    0;

It seems to have something to do with the magnitude of this line of code, because replacing that code with the following allowed the test to proceed successfully:

  Bits<32> value =
    (CSR[mhpmevent3].OF << 3) |
    (CSR[mhpmevent4].OF << 4) |
    (CSR[mhpmevent5].OF << 5) |
    (CSR[mhpmevent6].OF << 6) |
    (CSR[mhpmevent7].OF << 7) |
    (CSR[mhpmevent8].OF << 8) |
    (CSR[mhpmevent9].OF << 9) |
    (CSR[mhpmevent10].OF << 10) |
    (CSR[mhpmevent11].OF << 11) |
    (CSR[mhpmevent12].OF << 12) |
    (CSR[mhpmevent13].OF << 13) |
    (CSR[mhpmevent14].OF << 14) |
    (CSR[mhpmevent15].OF << 15) |
    (CSR[mhpmevent16].OF << 16) |
    (CSR[mhpmevent17].OF << 17) |
    (CSR[mhpmevent18].OF << 18) |
    (CSR[mhpmevent19].OF << 19) |
    (CSR[mhpmevent20].OF << 20) |
    (CSR[mhpmevent21].OF << 21) |
    #(CSR[mhpmevent22].OF << 22) |
    #(CSR[mhpmevent23].OF << 23) |
    #(CSR[mhpmevent24].OF << 24) |
    #(CSR[mhpmevent25].OF << 25) |
    #(CSR[mhpmevent26].OF << 26) |
    #(CSR[mhpmevent27].OF << 27) |
    #(CSR[mhpmevent28].OF << 28) |
    #(CSR[mhpmevent29].OF << 29) |
    #(CSR[mhpmevent30].OF << 30) |
    #(CSR[mhpmevent31].OF << 31) |
    0;

[dhower-qc]

Hmm. That looks like there is a performance bug while the compiler is trying to statically determine values. I should be able to figure it out with that example.

[omsuneri]

@ThinkOpenly i tested this out and teh error "Type checking" CSRs did not reproduced at all look in the ss if i'm going wrong or any advise

[ThinkOpenly]

@omsuneri,

teh error "Type checking" CSRs did not reproduced at all

It won't reproduce unless you have the code that produced the issue. We refactored that code so it works now, but it's very likely that the bug in the IDL compiler remains. Here is the commit that contained the code that caused the issue (it was not merged):
74b1147