https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83513
--- Comment #4 from Andrey Belevantsev <abel at gcc dot gnu.org> --- (In reply to Alexander Monakov from comment #2) > Thanks. So the fix for PR 82398 was incomplete. Here we have insns: > > i1: uid: 43 prio: 0 usefulness: 100% > i2: uid: 20 prio: 3 usefulness: 0% > i3: uid: 46 prio: 5 usefulness: 0% > > and sel_rank_for_schedule says i2 < i3 by priority difference, but i1 < i2 > && i3 < i1 by uid difference (btw it appears that either the comment or the > sense of the last tiebreaker is inverted). Now priority comparison code > doesn't account for the possibility of priority being 0. > > I think we should either > - simplify priority comparison to always compare by (prio + prio_adj) * use > (in which case comparison i2<?>i3 will fall down to uid comparison), or > - slightly expand it to always sort zero-usefulness exprs after non-zero > ones (even when they have priority 0 like i1 in the example). > > Andrey, do you have a preference? I think the second choice is better as then we do not fall down to uids for different priorities. I was hoping we would not get a zero usefulness in real life with REG_BR_PROB_BASE equal to 10000... sigh.
