RELOAD_OTHER bug?

[Joern RENNECKE]

DJ Delorie wrote:

>>>Does this mean that RELOAD_FOR_OTHER_ADDRESS reloads can never be
>>>merged with RELOAD_OTHER reloads?
>>> 
>>>      
>>>
>>Yes.  But if they load the same value as a RELOAD_OTHER input, they can 
>>share the same reload register.
>>    
>>
>
>So why does reload specifically check for RELOAD_FOR_OTHER_ADDRESS
>when deciding if a merge to RELOAD_OTHER is permitted?  Is this a bug
>in the current logic?
>
>	  for (j = 0; j < n_reloads; j++)
>	    if (i != j && rld[j].reg_rtx != 0
>		&& rtx_equal_p (rld[i].reg_rtx, rld[j].reg_rtx)
>		&& (! conflicting_input
>		    || rld[j].when_needed == RELOAD_FOR_INPUT_ADDRESS
>		    || rld[j].when_needed == RELOAD_FOR_OTHER_ADDRESS))
>	      {
>		rld[i].when_needed = RELOAD_OTHER;
>		rld[j].in = 0;
>		reload_spill_index[j] = -1;
>		transfer_replacements (i, j);
>  
>
That test checks that the value can actually live in the reload register 
not only during, but also
in-between (if there is such a time) the two reloads.  If there is a 
reload type available that is
suitable for the merged reload is another matter.
I see now that this code is in merge_assigned_reloads, so it might even 
be safe there to set the
reload type to RELOAD_FOR_OTHER_ADDRESS.  You'll have to check if the 
reload type from
that point onward is only needed to determine the time of the reload 
insn (rather than also the lifetime
of the reload register).