https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121440
Filip Kastl <pheeck at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
CC| |hubicka at gcc dot gnu.org
--- Comment #4 from Filip Kastl <pheeck at gcc dot gnu.org> ---
I bisected the speedup to this Honza's commit:
9f9c8d63a5822378e18f3f8f188df21c6104e18e is the first bad commit
commit 9f9c8d63a5822378e18f3f8f188df21c6104e18e
Author: Jan Hubicka <[email protected]>
Date: Fri Sep 26 12:39:07 2025 +0200
Fix integer overflow in profile_count::probability_in
This patch fixes integer overflow in profile_count::probability_in which
happens
for very large counts. This was probably not that common in practice until
scaled AutoFDO profiles were intorduces.
This was introduced as cut&paste from profile_probability implementation.
I reviewed multiplicaitons in the file for safety and noticed that in some
cases the code is over-protective. In profile_probability::operator/ we
alrady
scale that m_val <= other.m_val and thus we know result will be in the
range
0...max_probability. In profile_probability::apply_scale we deal with
30bit
value from profile_probability so no overflow can happen.
Honza notes that the commit is targeted mainly at AutoFDO and this PR isn't
about a profiled build. So it seems to me that the speedup happened more or
less by random chance.
But let's close the PR anyway.
