> It does seem like reload 0 should be RELOAD_FOR_ something _ADDR.
> What set it to RELOAD_OTHER?
Ok, we start with a RELOAD_OTHER for the zero_extendhisi. The MEM's
address eventually gets RELOAD_FOR_OTHER_ADDRESS. Part of that
address is split out into another RELOAD_FOR_OTHER_ADDRESS.
Separately, we have an RELOAD_FOR_OUTPUT_ADDRESS that matches it. The
OUTPUT_ADDRESS and OTHER_ADDRESS are merged into a RELOAD_OTHER at the
munged patch snippet below, where I added a check for OTHER_ADDRESS to
avoid regressing the priority. It seems to work, but I'm worried that
there's no logic to guarantee the order of output, other than the
sequence number, which is commented as part of the sort "so that qsort
is deterministic". Seems to be a recipe for future disaster.
Index: reload1.c
===================================================================
--- reload1.c (revision 108132)
+++ reload1.c (working copy)
@@ -6136,7 +6171,15 @@
|| rld[j].when_needed == RELOAD_FOR_INPUT_ADDRESS
|| rld[j].when_needed == RELOAD_FOR_OTHER_ADDRESS))
{
- rld[i].when_needed = RELOAD_OTHER;
+ if (rld[i].when_needed == RELOAD_FOR_OTHER_ADDRESS
+ || rld[j].when_needed == RELOAD_FOR_OTHER_ADDRESS)
+ rld[i].when_needed = RELOAD_FOR_OTHER_ADDRESS;
+ else
+ rld[i].when_needed = RELOAD_OTHER;
rld[j].in = 0;
reload_spill_index[j] = -1;
transfer_replacements (i, j);
