Created attachment 8912 [details] Testcase Consider the attached testcase. Running llc -mcpu=cortex-a9 on it yields assertions fail.
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.
(In reply to comment #5) > 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.