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).
