Vladimir Makarov <vmaka...@redhat.com> writes:
> On 13-06-19 2:31 PM, Richard Sandiford wrote:
>> Richard Sandiford <rdsandif...@googlemail.com> writes:
>>> Vladimir Makarov <vmaka...@redhat.com> writes:
>>>> Index: lra.c
>>>> ===================================================================
>>>> --- lra.c (revision 199753)
>>>> +++ lra.c (working copy)
>>>> @@ -306,11 +306,11 @@ lra_emit_add (rtx x, rtx y, rtx z)
>>>> || (disp != NULL_RTX && ! CONSTANT_P (disp))
>>>> || (scale != NULL_RTX && ! CONSTANT_P (scale)))
>>>> {
>>>> - /* Its is not an address generation. Probably we have no 3 op
>>>> + /* It is not an address generation. Probably we have no 3 op
>>>> add. Last chance is to use 2-op add insn. */
>>>> lra_assert (x != y && x != z);
>>>> - emit_move_insn (x, z);
>>>> - insn = gen_add2_insn (x, y);
>>>> + emit_move_insn (x, y);
>>>> + insn = gen_add2_insn (x, z);
>>>> emit_insn (insn);
>>>> }
>>>> else
>>> Could you add a comment to lra_emit_add saying why it has to be this
>>> way round (move y, add z)?
>> Ping.
> I am going to add a comment when I submit my next patch (it will happen
> today or tomorrow).
Thanks.
> The reason is simple as address segment is stored in y not in z and
> generation of addition of address segment to pseudo can fail (that is
> what happens for the PR).
Do you mean address segment in the x86 sense of "segment"? I was just
a bit confused because the current comment says "It is not an address
generation", whereas it sounds like addresses are involved somewhere.
I suppose the commutation rules are that Y should be "no less complicated"
than Z, so maybe it wins from that point of view too.
Richard
