------- Comment #5 from drow at gcc dot gnu dot org 2010-02-22 21:06 ------- (In reply to comment #3) > * What is the purpose of insn 12 here? It looks to me like this is dead code, > since r5 is restored in insn 38 (although, not knowing ARM so well, I may be > wrong).
I couldn't figure this out either. Where did it come from - was it so late that we never DCE'd it, or does something bizarre claim to be dependent on the value? > Note how the sched1 pass has switched the two insns around. The register > allocator now decides to use two new registers here, because r0 and r3 are > both > live. After RA, sched2 switches insn 9 and insn 10 again, and r2 and r3 become > available in insn 10 -- but this is too late. > > Question for the ARM maintainer now is: Why does sched1 want to swap insns 9 > and 10, when sched2 wants to swap them back again? I'm guessing, but presumably we want to separate the mul from the mla because they're dependent; the umull isn't. But I don't know what would swap them back again and that's probably the crux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42575
