[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling

[abel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889

--- Comment #23 from Andrey Belevantsev <abel at gcc dot gnu.org> 2013-01-24 13:37:05 UTC ---
You are right from the target maintainer point of view, as you understand what
really happens in the code.  But this is not what the compiler sees as the
relations between insns you are talking about are not always expressed in the
RTL.  Consider insns 17 and 23, not looking at the other insns.  From their RTL
there is no "clear control and data dependencies" at all, they don't mention
the same register or memory.  (You are saying that insn 17 represents a call
but it is not clear from its representation, too.)  

As I mentioned, the only reason insn 23 gets dependent on insn 17 is that
ira_implicitly_set_insn_hard_regs kicks in and says, we have a LINK_REGS
alternative in insn 23, and the corresponding reg class is small, let us
consider insn 23 clobber reg 65 (LR), and because insn 17 also clobbers reg 65
you get a dependency.  This was added with the sched-pressure code, which is
why I CC'd Vlad.  And this issue is not sel-sched specific, you need just to
disable the if (! reload_completed) at sched-deps.c:2805 with e.g. && INSN_UID
(insn) != 23, and remove the -fselective-scheduling flag, and you will see the
regular scheduler happily lift off insn 23 through insn 17 and place it before
insn 17, as there is no dependency that can be guessed by the regular
sched-deps analysis just by looking at the RTL of those insns.

If you want to have such a dependency, I'd suggest to add some specific clobber
as it is done for insn 17.  This will fix this particular issue, but in general
the question on the register renaming in the sel-sched remains, as we just see

17: r3 = rhs1
20: use(r3)
24: r3 = rhs2 

and we assume we can do

new1: r150 = rhs2
17: r3 = rhs1
20: use(r3)
new2: r3 = r150

and this will not create random dependencies between insn new1 and insn 17 as
it happens now.  Again, there is no dependencies that can be seen from the RTL
that prevent us from doing so.