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
happen.

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.