[Bug rtl-optimization/69102] [4.9/5/6 Regression] ICE: in move_op_ascend, at sel-sched.c:6138 with -fselective-scheduling2

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69102

--- Comment #5 from Richard Henderson <rth at gcc dot gnu.org> ---
(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.