Performance issue for read_verilog of nested for-loops with intermediate wire declaration

[gmagaf]

Version

Yosys 0.62 (git sha1 v0.62, g++ 15.2.0 -fPIC -O3)

On which OS did this happen?

Linux

Reproduction Steps

loops.v

`default_nettype none
module topEntity();  
  genvar i;
  generate
  for (i = 0; i < 128 * 4; i = i + 1) begin
    wire [383:0] ws;
    genvar j;
    for (j=0; j < 64; j = j + 1) begin
      localparam vec_index = 63 - j;
      assign ws[vec_index*6+:6] = j[0+:6];
    end
  end
  endgenerate
endmodule

`default_nettype wire

For the above reproducer

yosys -p "read_verilog loops.v"

seems to have poor performance. For the different bounds of i we have:

• i = 128 * 1 -> 2 sec
• i = 128 * 2 -> 8 sec
• i = 128 * 3 -> 21 sec
• i = 128 * 4 -> 44 sec

The issue does not occur when wire ws is declared in the inner-most loop or in top level.
The issue appears for smaller bounds of the loops if we add more nested loops:
loops4.v

`default_nettype none
module topEntity();  
  genvar i;
  generate
  for (i = 0; i < 24; i = i + 1) begin
    genvar j;
    for (j = 0; j < 5; j = j + 1) begin
      genvar k;
      for (k = 0; k < 5; k = k + 1) begin
        wire [383:0] ws;
        genvar l;
        for (l=0; l < 64; l = l + 1) begin
          localparam vec_index = 63 - l;
          assign ws[vec_index*6+:6] = l[0+:6];
        end
      end
    end
  end
  endgenerate
endmodule

`default_nettype wire

Expected Behavior

read_verilog performance should not differ for different levels of nested loop wire declarations.

Actual Behavior

read_verilog should be able to generate RTLIL with better time complexity with respect to the bounds of for-loops with intermediate wire declarations.

[martijnbastiaan]

To get a feel for the issue (mostly to see whether it was worth fixing on the Clash side), I did put it through an LLM, which resulted in a fairly small patch. This does seem to fix the issue and survive the existing test suite, but I don't feel comfortable putting it up for a PR as I can't judge the quality very well. Putting it here in case it's useful for anyone.

[rowanG077]

This is tagged as SystemVerilog but it's a plain verilog issue.

[widlarizer]

expand_genblock is known to be problematic. I'd take a stab at this but the direction we're taking is integrating slang (#5967) with the intention of directing users to that instead. That, and other things, are just a more meaningful uses of our time, and read_verilog is risky to evolve further. So I'm keeping this open, as the perf is indeed unreasonable, but won't be working on it myself. Even though I would accept a careful PR that would fix this (that isn't all-LLM), I wouldn't exactly encourage anybody to try to fix this, since it is a really reverse-engineering-heavy work in a fragile code context. I wouldn't be able to advise a contributor and would likely deprioritize the issue entirely.