RFA: enable LRA for rs6000 [patch for WRF]

Vladimir Makarov vmakarov@redhat.com
Tue Apr 23 21:02:00 GMT 2013


On 04/22/2013 09:55 PM, David Edelsohn wrote:
> On Mon, Apr 22, 2013 at 8:43 PM, Vladimir Makarov <vmakarov@redhat.com> wrote:
>
>>          * config/rs6000/rs6000.c (legitimate_lo_sum_address_p): Remove
>>          lra_in_progress guard for addressing something bigger than word.
> That will work, but I'm worried that it is too fragile.  Previously
> the code uniformly returned consistent values from the various
> legitimate address functions.  Changing the response based on
> lra_in_progress for various modes seems like a problem waiting to
> happen.
>
   LRA approach is different from reload one.  First of all LRA can 
create pseudos (not assigned yet to anything) and secondly LRA makes 
changes incrementally opposite to reload which makes all final rewriting 
code when it decides that a final solution is found.  The difference in 
approaches means that LRA can not use all reload macros and hooks 
completely without changes.  Although I tried to minimize the changes, 
they are still present.  For example, LRA will never use hooks which 
call push_reload which is completely oriented to reload pass.

   I'd not say that "the code uniformly returned consistent values". One 
place where lra_in_progress is needed exactly because of discrepancy 
between legitimize reload address hook (which can call push_reload and 
can not be used by LRA) and legitimate address hook.  Two other places 
in rs6000_emit_move for SDmode where lra_in_progress is used are because 
LRA can create and use spilled pseudos instead of using concrete memory 
slot as reload does.  And two the rest places are in calls of 
legitimate_const_pool_address_p where LRA actually querying in strict 
sense.  So I think the changes are minimal.

David, thanks for expressing the concern.  I hope I answered it. The 
future will show the reality not just our speculations.



More information about the Gcc-patches mailing list