patch to fix PR57559 for s390

[Richard Sandiford]

Vladimir Makarov <vmakarov@redhat.com> writes:
> On 13-06-19 2:31 PM, Richard Sandiford wrote:
>> Richard Sandiford <rdsandiford@googlemail.com> writes:
>>> Vladimir Makarov <vmakarov@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