https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127309
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2026-09-21
Status|UNCONFIRMED |NEW
--- Comment #2 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So if-converting a branch which is well predicated by hardware can be a net
loss. The question is do we have any information to indicate to the compiler
how to view this branch. I suspect not.
If we look at the .expand dump we have:
if (t_21 > 0)
goto <bb 6>; [59.00%]
else
goto <bb 5>; [41.00%]
;; succ: 6
;; 5
;; basic block 5, loop depth 1
;; pred: 4
_9 = _31 + 2147483647;
_2 = (int) _9;
;; succ: 6
;; basic block 6, loop depth 1
;; pred: 4
;; 5
# cstore_22 = PHI <t_21(4), _2(5)>
Note the compiler thinks this is around a 60-40 not taken/taken. That doesn't
say a whole lot about predictions, but that taken/not taken is used as a proxy
for predictability.
If I look at the branchy vs if-converted sequence, the former is likely 2c and
the latter is likely 3c. We're considering branches as cost 4.
Putting all that together, I think the if-converter is behaving as it should.
If I were to chase this I would be looking to see if we can get a more accurate
prediction from the static predictors. That may still not fix this problem,
but right now I don't see a path forward to fix this.
