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.
