------- Comment #11 from uweigand at gcc dot gnu dot org 2010-03-02 19:56 ------- (In reply to comment #10) > I don't see where reload is creating the whole instruction; maybe I am > misunderstanding that statement.
Well, after reload you have insn 624, which presumably didn't exist before. This was inserted by reload before the (original) insn 218 -- you didn't show the fixed-up version of insn 218 after reload, but I'm assuming it's probably a register-to-register (or -to-memory) move from the reload register (reg:DF 21) into whatever the register allocator has chosen to hold (reg/v:DF 203). The new insn 624 is not in any way a "fixed up" version of insn 218. Instead, it is a reload insn that was generated by reload to load some value (in this case the (mem:DF ...)) into some reload register. (That this happens to look similar to insn 218 before reload is just a coincidence.) As I mentioned, reload by default assumes that any move of any legitimate operand into any register is always valid and can by performed by a simple set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41176
