https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think threading unlikely paths is never worth it and usually NULL pointer
checks are statically predicted.
I guess one idea would be to scale BB cost based on entry_BB->count vs.
BB->count so we more quickly run into the threading size limit for unlikely
executed blocks? Likewise since we first evaluate all threading opportunities
in a function (do we?) we should sort them so we first thread the "best" one
and use a global threading limit instead one applied to each individual path
(so we'd just stop threading once we hit the limit).
Can we, for GCC 12, at least stop threading !maybe_hot_edge_p()? Eventually
we can produce sth like a maybe_hot_threading_path_p () taking into account
the whole path.
