On 2014-08-08, 2:53 PM, David Edelsohn wrote:
Hi, Vlad
Why does rs6000_emit_move need special support for SDmode with LRA and
not with reload?
rs6000_emit_move has also special SDmode support for *reload too*.
It is not implemented generically in reload as you wrote. Please, look
at the code with reload_in_progress nearby. So I am trying to do
basically the same as done by rs6000 back end for reload but by means of
LRA. The difference between code for reload and LRA is in that a
special stack slot is created for reload. Reload through a hook
SECONDARY_MEMORY_NEEDED_RTX provided by rs6000 back-end generates a move
using the stack slot and that triggers a special code generation in
rs6000_emit_move. So it is a trick, not a general support in reload.
LRA uses a spilled pseudo for this and don't use the hook at all. It
means that the stack slot created for reload is used only for SD moves.
LRA uses a common stack slot allocation techniques for spilled pseudos
which permits to share this slot for other purposes, generates a better
code, and uses less one hook. But basically code for LRA in
rs600_emit_move do the same as analogous code for reload.
But if you mean that general support you mentioned is the usage of
absolutely the same trick for LRA as for reload (through
SECONDARY_MEMORY_NEEDED_RTX), I could do this. But as I wrote it would
be worse code generation than LRA currently produces and using an
additional hook out of many already used by LRA.
In other words, why is this a specific fix for
rs6000 instead of a general improvement for reload?
Because it is too specific. It is about how rs6000 too specifically
implements sd load/store. For example, SECONDARY_MEMORY_NEEDED_RTX is a
creation only for rs6000. No other port uses it because the hook is
used for the trick I wrote above. I don't think other port will use the
trick in future.
SDmode has some bizarre restrictions on PPC, but one of the historical
advantages of GCC was reload's ability to support strange addressing
modes of processors. Why fix this in a target-specific way and then
possibly replicated this in other architectures instead of fixing it
more generally?
It is not about addressing. It is about machine description of insns.
If movsd_{load,store} insns were part of common move insns, we would
have no problem at all. But I guess, achieving this would be not
possible or easy. I believe Mike had serious reasons to do this such
way. I am not such a specialist in md writing as Mike.
If I could solve this problem only in LRA, I'd prefer to do this because
it is simpler for me as I don't need an approval.
