On 8/13/2026 12:46 AM, wangjue wrote:
Thanks. That is close, but it considers both dependency depth and
the number of instructions at each level.
For each instruction, the loop finds earlier instructions whose
destinations are used by its source and places it one level after the
deepest producer. Independent instructions remain at the same level.
The cost is then calculated for each level using the available
parallelism and summed across all levels. I will add a comment
explaining this.
Definitely deserves a comment. Thanks for explaining it, like Maxim I
stared at it a bit and found it non-obvious (though I had a reasonable
sense of what it was trying to do). Point being when we have something
that is subtle, we do try to comment it so future readers can quickly
understand the intent of the code.
It would be interesting to have two data points here:
1. How often (percentage) the above analysis succeeds and we calculate
parallel_cost.
E.g., is it
- "parallel_cost calculation is successful in 10% of noce_parallel_seq_cost()
invocations."
or is it
- "parallel_cost calculation is successful in .1% of noce_parallel_seq_cost()
invocations."
?
2. What is the histogram of how far parallel_cost is from serial_cost?
E.g., something like this:
- 1.0 >= parallel_cost/serial_cost > 0.8: 50% probability
- 0.8 >= parallel_cost/serial_cost > 0.6: 25% probability
- 0.6 >= parallel_cost/serial_cost > 0.4: 15% probability
- 0.4 >= parallel_cost/serial_cost > 0.2: 8% probability
- 0.2 >= parallel_cost/serial_cost > 0.0: 2% probability
I instrumented the draft and built all SPEC CPU2017 Integer rate
benchmarks on RISC-V. I have not collected data for other targets yet.
The analysis succeeded in 16,947 of 30,120 invocations (56.26%).
These calls came from 423 compiler processes. Among the successful
analyses, 15,024 cases (88.65%) produced a lower cost.
The parallel_cost / serial_cost histogram, using successful analyses
as the denominator, is:
1.0 >= ratio > 0.8: 1,955 (11.54%)
0.8 >= ratio > 0.6: 8,017 (47.31%)
0.6 >= ratio > 0.4: 6,820 (40.24%)
0.4 >= ratio > 0.2: 155 ( 0.91%)
0.2 >= ratio > 0.0: 0 ( 0.00%)
Yea, that data basically makes sense, especially for RISC-V where a
generalized conditional move always has 2 czeros which can issue in
parallel, so fully expect a huge cluster around that point.
A more interesting number would be how often we previously rejected an
if-conversion, but after accounting for parallelism we allow it. I'm not
necessarily suggesting you spend meaningful time to get that data, just
that I suspect a lot of the cases above are already being if-converted,
even with the huge inaccuracies in the cost model.
jeff
