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. Thanks, David
