Re: strub causing libgcc to fail to build on rl78-elf

[Jeff Law <jeffreyalaw@gmail.com>]

On 12/6/23 15:03, DJ Delorie wrote:
> Alexandre Oliva <oliva@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