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:37:50 -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> <CAGWvny=dYZRwTEu2HkqgdEzE5ZDsR2opbEkT8ok-URv2B_nXYg at mail dot gmail dot com>
On 04/23/2013 11:33 AM, David Edelsohn wrote:
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
Sorry, may be I missed some other places but
could you be more specific about the place where combining
lra_in_progress and mode happens now for legitimate address querying.
I guess I explained in my previous emails why the following change is
necessary in legitimate_lo_sum_address_p:
toc_ok_p = (lra_in_progress && TARGET_CMODEL != CMODEL_SMALL
&& small_toc_ref (x, VOIDmode));
lra_in_progress was removed in my latest change which now looks like the
if (GET_MODE_SIZE (mode) > UNITS_PER_WORD
&& !(/* ??? Assume floating point reg based on mode? */
TARGET_HARD_FLOAT && TARGET_FPRS && TARGET_DOUBLE_FLOAT
&& (mode == DFmode || mode == DDmode)))
So I can not see other places.