On 12/6/23 15:03, DJ Delorie wrote:
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.
Given we don't know the semantics of what goes on inside the MEM I think
rewriting would be extraordinarily difficult. Ultimately all this feels
like a limited reload pass implemented in the rl78 backend. You'd have
to look at all the operands, potentially spill one or more values,
arrange for input/output reloads, deal with clobbers (particularly
reloading the address given (clobber (mem (addr))).
I suspect that something in the virt->phys logic just doesn't know how
to check for mem constraints in user asms.
I looked briefly, it appears the code just punts rewriting all user
asms, but maybe I missed something.
I wouldn't lose any sleep if we had a way to simply disable strub for rl78.
Jeff
