[CombToSynth] Use parallel-prefix tree for unsigned comparisons

[uenoku]

This commit extends the unsigned comparison lowering to support multiple parallel-prefix architectures (Sklanskey, Kogge-Stone, Brent-Kung) in addition to the existing ripple-carry implementation. No functional change in prefix-tree/adder lowering.

Previously, all comparisons used a ripple-carry style implementation that processed bits sequentially from LSB to MSB, resulting in O(n) depth for n-bit comparisons. This was a significant performance bottleneck for wide comparisons. The comparison lowering is now refactored to use the same parallel-prefix tree algorithms as the adder, reducing depth to O(log n).

The comparison logic is formulated as a prefix computation where equal bits are computed as ~(a_i ^ b_i) and greater bits as ~a_i & b_i, with propagate and generate signals based on equality and greater-than conditions.

Integration tests for all architectures verify logical equivalence via circt-lec.

before/after for 64-bit unsigned comparision.

uenoku@pop-os ~/d/circt-synth (dev/hidetou/icmp-parallel) [1]> ../circt/build/bin/circt-synth bar.mlir -output-longest-path=- -o /dev/null
# Longest Path Analysis result for "icmp_unsigned"
Found 128 paths
Found 1 unique fanout points
Maximum path delay: 128
## Showing Levels
Level = 128       . Count = 1         . 100.00    %
## Top 0 (out of 1) fan-out points

uenoku@pop-os ~/d/circt-synth (dev/hidetou/icmp-parallel)> ./build/bin/circt-synth bar.mlir -output-longest-path=- -o /dev/null 
# Longest Path Analysis result for "icmp_unsigned"
Found 128 paths
Found 1 unique end points 
Maximum path delay: 14
## Showing Levels
Level = 14        . Count = 1         . 100.00    %
## Top 0 (out of 1) end points

[uenoku]

FileCheck test is missing in non-integration test and I'll add a test for parallel prefix tree.

[cowardsa]

Very neat - nice work and pleasing to see the longest path improvements - ideal how we can reuse the prefix computation.

For reduced overhead - could pass a flag to prevent the prefix computation generating a lot of gates that will then need to be removed by DCE? Namely, we are only interested in generating the carry-out and propagate out? (however the code already generates unused gates so its already far from optimal in terms of efficiency)

[uenoku]

could pass a flag to prevent the prefix computation generating a lot of gates that will then need to be removed by DCE? Namely, we are only interested in generating the carry-out and propagate out?

Good points, but I'm not sure there is a non-complicated way to prune prefix computation since it's hard to know beforehand which index is actually used by carry-out and propagate out in the last stage. I think we can change the prefix computation for comparison to use recursive function with memoization that by nature lazily computes ony necessary prefixes, but it requires quite a bit of changes for prefix tree generation functions we have now. So please let me stick with the current implementation for this PR.

[cowardsa]

could pass a flag to prevent the prefix computation generating a lot of gates that will then need to be removed by DCE? Namely, we are only interested in generating the carry-out and propagate out?

Good points, but I'm not sure there is a non-complicated way to prune prefix computation since it's hard to know beforehand which index is actually used by carry-out and propagate out in the last stage. I think we can change the prefix computation for comparison to use recursive function with memoization that by nature lazily computes ony necessary prefixes, but it requires quite a bit of changes for prefix tree generation functions we have now. So please let me stick with the current implementation for this PR.

Absolutely non-blocking for sure - just a thought for future improvements if we hit against performance issues.