RescheduleMIBelowKill is moving an INSERT_SUBREG instruction, and then it never gets revisited, so we don't insert the required COPY in front of it.

Interesting, looking into this... don't yet have a strong understanding of the change in behavior...

Honestly, I get lost in those giant nested loops. It might help to extract a few methods.

INSERT_SUBREG gets partial special treatment because we need to both insert a COPY in front and change the instruction itself into a subreg COPY.

Note that this reproduces for me even with r160228 reverted.

You touch it, you own it ;-)

Chad, ISTR you asking me about INSERT_SUBREG and RescheduleMIBelowKill. Do you remember how it is supposed to work?

Unfortunately, I don't recall.

You touch it, you own it ;-)

Careful what you wish for?

(And no, I'm not owning it... but I'll try to help when I can... ;])

I've mailed a patch that I think fixes this to -commits for review. I've included a (far too) lengthy write up of the debugging process I went through in the hope of learning whether I've got any clue how this thing works, and maybe helping some others learn as well.

Thanks, Chandler. It looks like I broke it in r159120. I suppose "you break it, you own it" takes precedence ;-)

To summarize Chandler's analysis, when an INSERT_SUBREG instruction is rescheduled, operand processing is deferring until we reach the instruction the second time. However, the code that rewrites INSERT_SUBREG to COPY was accidentally not deferred, so the second time around we see a COPY which isn't a 2-addr instruction.

Fix committed in r160443.