This is the mail archive of the
mailing list for the GCC project.
Re: RFA: enable LRA for rs6000 [patch for WRF]
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: Vladimir Makarov <vmakarov at redhat 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:33:35 -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> <5176A2D4 dot 7020101 at redhat dot com>
On Tue, Apr 23, 2013 at 11:03 AM, Vladimir Makarov <email@example.com> 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.
> 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.
I don't think that you understood my concern. I am not concerned
about adding lra_in_progress. I am concerned about combining
lra_in_progress with the mode. I would like an explanation why it is
correct for the result of legitimate address functions to vary with
lra_in_progress combined with the mode. Not simply that it works.
The issue should be if an offsettable address is valid and the size of