Summary: | [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 3) in fill_vec_av_set in selective scheduler | ||
---|---|---|---|
Product: | gcc | Reporter: | Arseny Solokha <asolokha> |
Component: | rtl-optimization | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | abel, amonakov |
Priority: | P3 | Keywords: | ice-checking, ice-on-valid-code |
Version: | 8.0 | ||
Target Milestone: | 8.0 | ||
Host: | Target: | ||
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: | 2017-12-21 00:00:00 | |
Bug Depends on: | |||
Bug Blocks: | 82407 |
Description
Arseny Solokha
2017-12-20 17:46:47 UTC
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? > (btw it appears that either the comment or the sense of the last tiebreaker is inverted)
I have to take that back, I was confused by the unusual tmp vs. tmp2 order:
sel_rank_for_schedule (const void *x, const void *y)
{
expr_t tmp = *(const expr_t *) y;
expr_t tmp2 = *(const expr_t *) x;
... and the ordering sel_rank_for_schedule seeks to produce is "worse insns first, better last". The rest of the previous comment still stands.
(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. Author: amonakov Date: Tue Dec 26 14:34:33 2017 New Revision: 256001 URL: https://gcc.gnu.org/viewcvs?rev=256001&root=gcc&view=rev Log: sel-sched: fix zero-usefulness case in sel_rank_for_schedule (PR 83513) PR rtl-optimization/83513 * sel-sched.c (sel_rank_for_schedule): Order by non-zero usefulness before priority comparison. Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched.c Fixed. |