[Bug rtl-optimization/69102] [4.9/5/6 Regression] ICE: in move_op_ascend, at sel-sched.c:6138 with -fselective-scheduling2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69102 --- Comment #6 from Andrey Belevantsev --- Author: abel Date: Mon Mar 21 07:52:05 2016 New Revision: 234359 URL: https://gcc.gnu.org/viewcvs?rev=234359=gcc=rev Log: gcc/ PR rtl-optimization/69102 * sched-deps.c (sched_analyze_insn): Do not set last_args_size field when we have a readonly dependency context. testsuite/ PR rtl-optimization/69102 * gcc.c-torture/compile/pr69102.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr69102.c Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/69102] [4.9/5/6 Regression] ICE: in move_op_ascend, at sel-sched.c:6138 with -fselective-scheduling2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69102 --- Comment #5 from Richard Henderson --- (In reply to Andrey Belevantsev from comment #4) > Created attachment 37550 [details] > proposed patch > > The problem here is readonly dependence contexts in selective scheduler. > We're trying to cache the effect of initializing a dependence context with > remembering that context and setting a readonly bit on it. When first > moving the insn 43 with REG_ARGS_SIZE note through the insn 3 (a simple eax > set) we also set the last_args_size field of the context. Later, when we > make a copy of insn 43 and try to move it again through insn 3, we take the > cached dependency context and notice the (fake) dep with last_args_size > insn, which is the old insn 43. Then the assert saying that we should be > able to lift the bookkeeping copy up the same way as we did with the > original insn breaks. If you're going to make two attempts to move insn 43 past insn 3, and you've cached stuff from the previous attempt, it seems to me the bug is elsewhere in not backing out the cached stuff properly. Just ignoring the dependency the second time around seems like a source of bugs. But I freely admit I don't understand the caching going on here. > Richard, is it safe to make copies of REG_ARGS_SIZE insns? In general it should be ok, assuming that you validate everything else about where you place the insn. E.g. the insn 43 here, which decrements the stack. So long as all paths to the post-dominated call or ARGS_SIZE insn see exactly one copy, everything will be ok.
[Bug rtl-optimization/69102] [4.9/5/6 Regression] ICE: in move_op_ascend, at sel-sched.c:6138 with -fselective-scheduling2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69102 --- Comment #4 from Andrey Belevantsev --- Created attachment 37550 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37550=edit proposed patch The problem here is readonly dependence contexts in selective scheduler. We're trying to cache the effect of initializing a dependence context with remembering that context and setting a readonly bit on it. When first moving the insn 43 with REG_ARGS_SIZE note through the insn 3 (a simple eax set) we also set the last_args_size field of the context. Later, when we make a copy of insn 43 and try to move it again through insn 3, we take the cached dependency context and notice the (fake) dep with last_args_size insn, which is the old insn 43. Then the assert saying that we should be able to lift the bookkeeping copy up the same way as we did with the original insn breaks. Fixed by the attached patch that makes us notice only deps with the current producer insn. I'd need to test it more thoroughly on several arches though. Richard, is it safe to make copies of REG_ARGS_SIZE insns? I've read the original ML thread of the sched-deps REG_ARGS_SIZE patch and couldn't quite figure it out -- with the current deps setting nothing prevents us from moving the first REG_ARGS_SIZE insn up and creating bookkeeping copies on the paths where it is inaccessible.
[Bug rtl-optimization/69102] [4.9/5/6 Regression] ICE: in move_op_ascend, at sel-sched.c:6138 with -fselective-scheduling2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69102 Andrey Belevantsev changed: What|Removed |Added Status|NEW |ASSIGNED CC||abel at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |abel at gcc dot gnu.org
[Bug rtl-optimization/69102] [4.9/5/6 Regression] ICE: in move_op_ascend, at sel-sched.c:6138 with -fselective-scheduling2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69102 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at redhat dot com --- Comment #3 from Jeffrey A. Law --- Downgrading to P4 on the basis that it's specific to sel-sched that's only used by default on ia64, a dead architecture.
[Bug rtl-optimization/69102] [4.9/5/6 Regression] ICE: in move_op_ascend, at sel-sched.c:6138 with -fselective-scheduling2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69102 --- Comment #2 from Richard Henderson --- The only additional deps in this entire function by the quoted patch are three sequential insns involved in a call that use REG_ARGS_SIZE. But all of these are well-removed from the ICE. The instruction that is producing the ICE is (gdb) call debug_insn(insn) ([((3;ax=0x5;)type:use;count:2;)prio:0;orig_bb:3;];seqno:14;) which ought to have dependencies only in setting of EAX. Whether this is actually so, I can't quite tell from if (has_dep_p[DEPS_IN_INSN]) /* We have some dependency that cannot be discarded. */ return MOVEUP_EXPR_NULL; But regardless, sel-sched.c appears to be not handling valid dependency info.
[Bug rtl-optimization/69102] [4.9/5/6 Regression] ICE: in move_op_ascend, at sel-sched.c:6138 with -fselective-scheduling2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69102 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-08 CC||jakub at gcc dot gnu.org, ||rth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r207518.
[Bug rtl-optimization/69102] [4.9/5/6 Regression] ICE: in move_op_ascend, at sel-sched.c:6138 with -fselective-scheduling2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69102 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.9.4
