http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889
--- Comment #11 from Andrey Belevantsev <abel at gcc dot gnu.org> 2013-01-21 10:15:31 UTC --- (In reply to comment #10) > Neither insn 24/145 nor insn 28 move through insn 17. The two UNSPEC 44 insn > (LC..2,, LCM..2) are inputs to insn 17. The pseudos are moved into r3 and r4, > which are the inputs to insn 17. You mean insn 23, not insn 28, right? I'm not sure how insns 23/24 could be inputs to insn 17, as they move up through insn 17. I don't see full RTL so I'm guessing here. Unfortunately, libbacktrace didn't work for the dump you provided, so I only see that for insn 23 we generate a "general dependency" meaning that it is not connected to lhs or rhs of the insn, but I don't know where exactly it comes from. We do not generate such dependency for insn 24, while they differ only in lhs -- the former having a pseudo, the latter a hard register r3. I think this could be fixed by making the same kind of dependency for insn 24, but I'm unable to make the compiler generate it, as to get insn 17 I need TLS support not available in the cross compiler. In general, would you allow insn 24 to move past insn 17 with the new register or does it have to be r3 in insn 24?
