This is the mail archive of the
mailing list for the GCC project.
Re: RFA: enable LRA for rs6000 [patch for WRF]
- From: Vladimir Makarov <vmakarov at redhat dot com>
- To: David Edelsohn <dje dot gcc at gmail dot com>
- Cc: Michael Meissner <meissner at linux dot vnet dot ibm dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, "Bergner, Peter" <bergner at vnet dot ibm dot com>, aavrunin at redhat dot com
- Date: Tue, 23 Apr 2013 11:03:48 -0400
- Subject: Re: RFA: enable LRA for rs6000 [patch for WRF]
- References: <5166F34C dot 30901 at redhat dot com> <20130415224853 dot GA17643 at ibm-tiger dot the-meissners dot org> <20130416225639 dot GA16621 at ibm-tiger dot the-meissners dot org> <516EAE5D dot 4080601 at redhat dot com> <20130417161042 dot GA22186 at ibm-tiger dot the-meissners dot org> <51705B25 dot 6020402 at redhat dot com> <5171B43B dot 5070400 at redhat dot com> <20130422043535 dot GC22536 at bubble dot grove dot modra dot org> <51758EF5 dot 8050209 at redhat dot com> <20130422193149 dot GA5792 at ibm-tiger dot the-meissners dot org> <5175D919 dot 1070704 at redhat dot com> <CAGWvnynixrVKFtcTz6fqW1TbU1ZJ=V5yT9m67o=mPuASodHtJg at mail dot gmail dot com>
On 04/22/2013 09:55 PM, David Edelsohn wrote:
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.
On Mon, Apr 22, 2013 at 8:43 PM, Vladimir Makarov <email@example.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
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.