https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127309
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org
Blocks|120763 |
--- Comment #3 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So if we add a bit more context we *may* have some information to guide branch
prediction. We'll have to bring in Honza who has owned that space for a long
time.
_31 = _32 + _34;
t_21 = (int) _31;
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
So when t21 (which is just _31 interpreted as a signed integer) is less than
zero, then we add MAX_INT. That hints of a correction step to bring a value
back into range -- which we might be able to consider as fairly or even highly
unlikely. It's a lot like saturations and clamps in that regard. Anyway,
CC'd Honza on this to get his thoughts. ANyway, not really working on this.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763
[Bug 120763] [meta-bug] Tracker for bugs to visit during weekly RISC-V meeting
