Hello, Jeff, DJ,
Thanks for the info.
On Dec 7, 2023, Jeff Law <jeffreya...@gmail.com> wrote:
> 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.
*nod*, the virt-to-phys "reloader" should care of it it, but it doesn't
because it explicitly punts on most ASMs, and it sort-of implicitly
punts on inputs-only asms like the one in strub.c.
> Given we don't know the semantics of what goes on inside the MEM I
> think rewriting would be extraordinarily difficult.
ISTM that it would need to know what's inside, any more than it (or
reload) does. It just needs to find (or make) some available phys
register and use that as the address instead of the virt register, like
it presumably does for other kinds of insns.
> I wouldn't lose any sleep if we had a way to simply disable strub for rl78.
Now that we have easy means to do that, it became irresistible ;-)
Tested building libgcc (all multilibs) with a cross rl78-elf. Ok to install?
rl78 allocation of virtual registers to physical registers doesn't
operate on asm statements, and strub uses asm statements in the
runtime and in the generated code, to the point that the runtime
won't build. Force strub disabled on that target.
for gcc/ChangeLog
* config/rl78/rl78.c (TARGET_HAVE_STRUB_SUPPORT_FOR): Disable.
---
gcc/config/rl78/rl78.cc | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/gcc/config/rl78/rl78.cc b/gcc/config/rl78/rl78.cc
index 5d8fddbd905a4..f3507280859b0 100644
--- a/gcc/config/rl78/rl78.cc
+++ b/gcc/config/rl78/rl78.cc
@@ -4972,6 +4972,11 @@ rl78_preferred_reload_class (rtx x ATTRIBUTE_UNUSED,
reg_class_t rclass)
}
+/* The strub runtime uses asms, and physical register allocation won't
+ deal with them, so disable it. */
+#undef TARGET_HAVE_STRUB_SUPPORT_FOR
+#define TARGET_HAVE_STRUB_SUPPORT_FOR hook_bool_tree_false
+
struct gcc_target targetm = TARGET_INITIALIZER;
#include "gt-rl78.h"
--
Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice but
very few check the facts. Think Assange & Stallman. The empires strike back
