Alexandre Oliva <ol...@gnu.org> writes:
> This looks like a latent bug in the port.
I'm not surprised, that port was weird.
> This was just a plain asm insn in strub.c:
>
> /* Make sure the stack overwrites are not optimized away. */
> asm ("" : : "m" (end[0]));
>
> whose constraint passes during reload, rl78_alloc_physical_registers
> leaves it alone and clears virt_insns_ok, so when cprog_hardreg attempts
> to extract constraints again, rl78_as_legitimate_address rejects r8 as
> the address because virt insns are no longer ok.
Some background: the "virtual" registers are memory-mapped registers
that use a common addressing scheme to access non-mapped registers.
When we convert from virtual to physical, we can map that reg to a
physical reg, or we replace the reg with a mem, but then usually have to
split up the insn.
For this insn, "converting" should have mapped or reloaded r8 to a valid
address register. I doubt we have a way to have two patterns for user
asms like we do for, say, addhi3.
I suspect that something in the virt->phys logic just doesn't know how
to check for mem constraints in user asms.
> I'm not at all familiar with this port, and I don't know what was
> supposed to happen here, but ISTM that either physical registers should
> be allocated for asms, or non-B0 regs should be accepted in asms.
non-bank-zero registers aren't valid as real address registers, because
in gcc's reality they *are* mems. The chip can bank switch them, but
gcc doesn't (the interrupt handlers, being asm, can do so, which is why
one bank is reserved for that).
