Alan Modra wrote:
> Normally, reload 2, the secondary reload for reload 3, would result in
> a call to reload_v16qi_si_load with (reg:V16QI 78 1) as its "reg"
> argument, and the mem home for pseudo reg 159 as its "mem" arg.
>
> However, reload1.c:choose_reload_regs has code to, as the comment
> says:
> /* First see if this pseudo is already available as reloaded
> for a previous insn.
>
> In this case reload finds such a register, so reload_v16qi_si_load
> then sees the register as its "mem" argument, and spits the dummy.
This still seems odd to me, I don't think the intent was that the
back-end secondary reload code is supposed to handle such cases.
Instead, there's code in emit_input_reload_insns that is supposed
to re-check whether a secondary reload is still needed if something
changed significantly, e.g. if a value was inherited:
/* If we have a secondary reload, pick up the secondary register
and icode, if any. If OLDEQUIV and OLD are different or
if this is an in-out reload, recompute whether or not we
still need a secondary register and what the icode should
be. If we still need a secondary register and the class or
icode is different, go back to reloading from OLD if using
OLDEQUIV means that we got the wrong type of register. We
cannot have different class or icode due to an in-out reload
because we don't make such reloads when both the input and
output need secondary reload registers. */
Note the condition "if OLDEQUIV and OLD are different" should be
true if the input value was inherited. Can you check whether
this case is hit with your test case?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
