On 8/10/2026 8:20 PM, wangjue wrote:
Hi Jeff
Which gets repeated 2 more times for the other values. The sgt insn is
repeated and the only obvious redundancy. Avoiding the redundancy would
help, but likely would only bring the required cost down to 7 to trigger
if-conversion (which still seems quite high). However, it may still be
worth eliminating that redundancy as doing so would likely result
if-converting cases where we need two generalized conditional moves at
just a branch cost of 4. I'll probably file that as a PR momentarily.
I agree with your conclusions.
I also experimented locally with sharing the condition across the converted
sets, so the comparison is emitted only once. For the MCF testcase, this
changes the sequence from:
3 sgt + 6 czero + 3 add
to:
1 sgt + 6 czero + 3 add
This removes the redundant comparisons and makes the initial costing more
accurate. However, even after this change, the three-select case still does not
if-convert with the normal C950 cost setting. A cost-model adjustment is still
needed for the optimization to trigger. My local shared-condition changes are
only a draft at this point and are not ready for submission.
Understood.
For the 3+ case I think we are going to need to do something with the
cost model, possibly along the lines of what you did. I think I've got
enough info now to dive into what you did and draw some conclusions.
I also completed a full SPEC CPU2017 integer regression on C950 with the
cost-model patch. The results are:
gcc: about +1%
xalancbmk: about +2%
deepsjeng: about +3.5%
mcf: about +5%
The other benchmarks show no significant performance change.Since all
measurable changes are positive, I think the existing branch-cost model is
likely too conservative for RTL if-conversion on C950.
Since the adjustment is limited to the C950 RTL noce profitability threshold
and the full regression results are positive, I hope we can move forward with
this patch.
We were discussing this a bit further in the patchwork meeting today.
I think the key insight is from a costing standpoint we are not taking
parallelism into account which makes the cost model wildly inaccurate as
we move into higher performance designs.
Right now the costing model looks at each insn in the sequence and costs
it individually, then sums them. That reasonable for a 1-wide design.
But for cases like you're running into those czeros all can execute in
parallel. If we go back to the original 3 sgt, 6 czero 3 add sequence
that's a 12 insns and 1-wide would be a cost of around 48 units.
If we think about a 4-wide design the 3 sgts execute in parallel, then 4
czeros, then 2 more czeros, then the 3 adds which should be around 16
units. On an 8-wide it'd be 3 sgts, 6 czeros and 3 adds, so a cost of
around 12 units since the dependency tree only has 3 levels and each
level can be handled single cycle by the hardware.
Now we can't really run the scheduler at that point on the fragment to
get latency of the sequence and we probably don't want build a full
dependency height analysis into the costing hook, but we ought to be
able to do significantly better than we are now. I'm thinking we
probably want to attack this problem first since it's pervasive and
should help all superscalar designs by bringing significantly more
accuracy to the costing model.
Jeff
