In this PR, we have an endless cycle in LRA, generating ever more instructions. The relevant portions of the dump seem to be these: ********** Local #9: ********** Creating newreg=130 from oldreg=128, assigning class CREG to r130 18: {r117:DI=unspec/v[[r129:SI*0x8+r123:SI],r117:DI,r122:SI,r130:SI,0x8005] 62;[r129:SI*0x8+r123:SI]=unspec/v[0] 62;flags:CCZ=unspec/v[0] 62;} ********** Assignment #7: ********** Assigning to 130 (cl=CREG, orig=114, freq=1148, tfirst=130, tfreq=1148)... 2nd iter for reload pseudo assignments: Reload r130 assignment failure Spill r87(hr=5, freq=4296) Spill r123(hr=4, freq=1148) Spill reload r129(hr=2, freq=1148) ********** Local #11: ********** Spilling non-eliminable hard regs: 6 Creating newreg=131, assigning class GENERAL_REGS to address r131 Change to class INDEX_REGS for r131 ********** Assignment #8: ********** Assigning to 131 (cl=INDEX_REGS, orig=131, freq=1148, tfirst=131, tfreq=1148)... Trying 0: spill 117(freq=1722) Now best 0(cost=574, bad_spills=0, insn_pseudos=1) Trying 1: spill 117(freq=1722) Trying 2: spill 130(freq=1148) Now best 2(cost=0, bad_spills=0, insn_pseudos=1) Trying 3: spill 122(freq=1148) Trying 4: spill 129(freq=1148) ********** Local #12: ********** Creating newreg=133 from oldreg=130, assigning class CREG to r133 What seems to happen is that in the "Assignemnt #8" phase, we're considering one new reload reg only, and we end up spilling r130, which only allows a register from a single class. Then we reload r130 again and make r133, and the cycle starts. Reload is designed in a way to avoid cycles and to process all reloads for an insn in order of ascending class so as to avoid this kind of issue. With LRA I'm really not sure how to fix this properly, but the following patch seems to cure the PR at least, by recognizing when we're about to spill a reload reg whose assigned class contains only contains a single register. Bootstrapped and tested on x86_64-linux, ok? Bernd