On 04/23/2013 11:33 AM, David Edelsohn wrote:
On Tue, Apr 23, 2013 at 11:03 AM, Vladimir Makarov <vmaka...@redhat.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.
Vlad,
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
the offset.
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
original code:
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)))
return false;
So I can not see other places.
