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