https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83513
Alexander Monakov <amonakov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |abel at gcc dot gnu.org
Blocks| |82407
--- Comment #2 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
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?
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82407
[Bug 82407] [meta-bug] qsort_chk fallout tracking
