Hi, Vlad
Thanks for the explanation.
The patch is okay.
Thanks, David
On Fri, Aug 8, 2014 at 5:26 PM, Vladimir Makarov <vmaka...@redhat.com> wrote:
> 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.
>
