reload_reg_reaches_end_p fix

[Bernd Schmidt]

This fixes a reload problem found by Tom de Vries while testing another
patch. An analysis of the problem is in PR50249. Essentially, we have
multiple reloads with the same type, for the same operand, feeding each
other and reusing the same register:

Reload 1: reload_in (SI) = (reg/f:SI 10 sl [588])
        BASE_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0)
        reload_in_reg: (reg/f:SI 10 sl [588])
        reload_reg_rtx: (reg:SI 1 r1)
Reload 2: reload_in (SI) = (mem:SI (reg/f:SI 10 sl [588]))
        LO_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0), can't combine
    reload_in_reg: (reg:SI 379)
        reload_reg_rtx: (reg:SI 1 r1)

One might wonder why the first reload isn't using
RELOAD_FOR_OPADDR_ADDR. All the reload types are rewritten in
find_reloads and the last stage of that follows this comment:
 /* Scan all the reloads, and check for RELOAD_FOR_OPERAND_ADDRESS reloads.
     If we have more than one, then convert all RELOAD_FOR_OPADDR_ADDR
     reloads to RELOAD_FOR_OPERAND_ADDRESS reloads.

So, presumably this is valid, and it looks like reload_reg_reaches_end
simply does not deal with this case. The following patch just adds a
loop to look for other reloads that look the same in this way. I've
bootstrapped and tested it on i686-linux; Tom has tested a few other
targets (although I'm not totally sure for which gcc version); it
appears to fix some Thumb libstdc++ testsuite failures.

Thoughts? I plan to install this tomorrow or so unless someone sees a
problem.


Bernd
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: for-tom.diff
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20110922/4a81d5eb/attachment.ksh>