https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591
Roman Zhuykov <zhroma at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2019-11-27
Assignee|unassigned at gcc dot gnu.org |zhroma at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Roman Zhuykov <zhroma at gcc dot gnu.org> ---
Oops, it seems that non-zero sms-dfa-history is untested since modulo-sched was
added in 2004.
This bugs is latent since r177235 in 2011, and logic is similar to bug 84032
comment #4.
When we schedule some insn into row R we check that DFA can't see any conflicts
in rows R-H .. R+H (modulo II), where H=sms-dfa-history. So, when we schedule
branch into row R some of its neighbours were not yet scheduled and DFA tells
OK.
While scheduling neighbours DFA may check some nearby rows, for example, rows
[R+1-H .. R+1+H] or something like that, but not exactly [R-H .. R+H]. Later
we decide to temporarily remove branch insn from schedule and are pretty sure
we could put it back (if rescheduling to another row fails). And this time DFA
shows a conflict, because now all branch neighbours are scheduled already.
Attached untested patch fixes this by running extra DFA checks for all rows
[x-H..x+H] where X is any value in range [R-H,R+H], thus eliminating the issue.
Certainly, these checks are expensive enough, so I also prepated a patch about
modulo-sched params, which will set max sms-dfa-history value to 16. While at
it, the patch also fixes other issues about sms parameters.
