https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475
--- Comment #10 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- (In reply to Richard Biener from comment #9) > 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). Yes, we first queue all threading opportunities and then reorganize the blocks at the end. > > 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. Sure, sounds reasonable, especially since as we get the last holdout converted to the new model (DOM threading), we'll have even more threading opportunities which could use some pruning. The whole cost model, as well as profiling, etc, was beyond the scope of my work this year. I'm curious if Jeff had any long term plans for this?
