Fix (work around) LRA infinite loop, PR78911

[Bernd Schmidt]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lra-singleton.diff
Type: text/x-patch
Size: 3765 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20170303/6a93e17e/attachment.bin>