[Bug target/84301] [6/7/8 Regression] ICE in create_pre_exit, at mode-switching.c:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84301 --- Comment #5 from Alexander Monakov --- Author: amonakov Date: Wed Apr 11 14:32:32 2018 New Revision: 259321 URL: https://gcc.gnu.org/viewcvs?rev=259321=gcc=rev Log: sched-rgn: run add_branch_dependencies for sel-sched (PR 84301) PR target/84301 * sched-rgn.c (add_branch_dependences): Move sel_sched_p check here... (compute_block_dependences): ... from here. testsuite/ * gcc.target/i386/pr84301.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr84301.c Modified: trunk/gcc/ChangeLog trunk/gcc/sched-rgn.c trunk/gcc/testsuite/ChangeLog
[Bug target/84301] [6/7/8 Regression] ICE in create_pre_exit, at mode-switching.c:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84301 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/84301] [6/7/8 Regression] ICE in create_pre_exit, at mode-switching.c:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84301
--- Comment #4 from Alexander Monakov ---
Moreover, without --param selsched-max-lookahead=2 sel-sched moves both the
assignment and use into middle of BB 2, breaking the assumption in
mode-switching that retval use is the last insn:
249 /* If this function returns a value at the end, we have to
250insert the final mode switch before the return value copy
251to its hard register. */
252 if (EDGE_COUNT (EXIT_BLOCK_PTR_FOR_FN (cfun)->preds) == 1
253 && NONJUMP_INSN_P ((last_insn = BB_END (src_bb)))
254 && GET_CODE (PATTERN (last_insn)) == USE
255 && GET_CODE ((ret_reg = XEXP (PATTERN (last_insn), 0))) == REG)
(independently of max-pending-list-length being 0 or not).
It seems a bit surprising that mode-switching needs to treat return value
specially, but more importantly, are the restrictions on return value register
set/use placement written down somewhere?
I don't see any explicit dependencies or barriers either, so isn't this like a
repeat of cc0 situation? What are other (dozens of) RTL passes doing to avoid
disturbing the required order?
Looking via gdb, apparently what pins those uses/clobbers to BB end for
haifa-sched is:
2728 /* Selective scheduling handles control dependencies by itself. */
2729 if (!sel_sched_p ())
2730add_branch_dependences (head, tail);
but the function doesn't do what it says on the tin:
2432 /* Add dependences so that branches are scheduled to run last in their
2433block. */
2434 static void
2435 add_branch_dependences (rtx_insn *head, rtx_insn *tail)
2436 {
2437 rtx_insn *insn, *last;
2438
2439 /* For all branches, calls, uses, clobbers, cc0 setters, and
instructions
2440 that can throw exceptions, force them to remain in order at the end
of
2441 the block by adding dependencies and giving the last a high priority.
2442 There may be notes present, and prev_head may also be a note.
[Bug target/84301] [6/7/8 Regression] ICE in create_pre_exit, at mode-switching.c:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84301 Jakub Jelinek changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I think --param max-pending-list-length=0 is just a pathological setting that doesn't make much sense, it basically kills all sched-deps handling and replaces it with just dependencies on the single element flush list. That said, when looking at what dependencies are there on the testcase without that param, I don't see any dependencies between those insns (clobber of , set ax and use ax) and the two the scheduler inserts in between those that upset mode switching.
[Bug target/84301] [6/7/8 Regression] ICE in create_pre_exit, at mode-switching.c:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84301 --- Comment #2 from Jakub Jelinek --- Started with r217331.
[Bug target/84301] [6/7/8 Regression] ICE in create_pre_exit, at mode-switching.c:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84301 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-09 CC||abel at gcc dot gnu.org, ||amonakov at gcc dot gnu.org, ||jakub at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/84301] [6/7/8 Regression] ICE in create_pre_exit, at mode-switching.c:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84301
--- Comment #1 from Uroš Bizjak ---
The function should have either be declared void or with a value return.
Otherwise, selective scheduler should be taught to not separate (insn 16) from
its use (insn 19):
...
(insn 17 9 18 2 (clobber (reg/i:SI 0 ax)) "pr84301.c":13 -1
(nil))
(insn 18 17 16 2 (clobber (reg:SI 0 ax [orig:94 ] [94]))
"pr84301.c":13 -1
(nil))
(insn 16 18 10 2 (set (reg/i:SI 0 ax)
(reg:SI 0 ax [orig:94 ] [94])) "pr84301.c":13 86
{*movsi_internal}
(nil))
(insn 10 16 27 2 (parallel [
(set (reg:DI 2 cx [orig:96 lr ] [96])
(minus:DI (reg:DI 2 cx [orig:96 lr ] [96])
(reg:DI 1 dx [orig:88 _2 ] [88])))
(clobber (reg:CC 17 flags))
]) "pr84301.c":10 278 {*subdi_1}
(nil))
(insn 27 10 11 2 (set (reg:DI 1 dx [98])
(reg:DI 2 cx [orig:96 lr ] [96])) "pr84301.c":10 85 {*movdi_internal}
(nil))
(insn 11 27 19 2 (set (reg:CCGC 17 flags)
(compare:CCGC (reg:DI 1 dx [98])
(const_int 1 [0x1]))) "pr84301.c":10 12 {*cmpdi_1}
(nil))
(insn 19 11 21 2 (use (reg/i:SI 0 ax)) "pr84301.c":13 -1
(nil))
...
The assert in mode-switching.c is there to catch the above case.
So, probably ice-on-ivalid-code with selective scheduling.
[Bug target/84301] [6/7/8 Regression] ICE in create_pre_exit, at mode-switching.c:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84301 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Component|rtl-optimization|target Target Milestone|--- |6.5 Summary|ICE in create_pre_exit, at |[6/7/8 Regression] ICE in |mode-switching.c:451|create_pre_exit, at ||mode-switching.c:451
