From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 782A03858CD1 for ; Sat, 9 Dec 2023 02:18:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 782A03858CD1 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 782A03858CD1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702088312; cv=none; b=xt4PbI19wJkFHHIijbD8pma2ZOKDFI7MyuFijoI7AgqdLlLJq0hYyyJXfMAwydQmbBQJP0xPZ7sgHXKYRlCEFjKcTZOEdD1DxIzXwDXF9/c+E+tLz2RYmrc5Hnxjy3IGDyLIMAPsHYjFOc6JAj0ecS9SLrpUR3cvpfsinqY/qtM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702088312; c=relaxed/simple; bh=LKZ3kAVx9jfdqGTSNdttHNQOPvyO28Kc0e8yi9VZ1Wk=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=SmkCERah/rnm60Cu8pL0vrr2jILqop0bgV2T85W+dsBulXDlJlJ+7d3hUSNhvuDAUFOEvBijoHGVmITHlWL0uuNQKSkgiQOUXjbYjrPKyoCOM1y+s5vhq7LKgH3cOWNHhO86jEUFucIrjYHSB9jF9RwOzCjzmxrz6SO1+jQ5Tug= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from linux-libre.fsfla.org ([2001:470:142:5::54] helo=free.home) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rBmvG-0007E7-CZ; Fri, 08 Dec 2023 21:18:30 -0500 Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 3B92IMZp317517 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 8 Dec 2023 23:18:22 -0300 From: Alexandre Oliva To: Jeff Law Cc: DJ Delorie , gcc@gcc.gnu.org Subject: [PATCH] strub: disable on rl78 Organization: Free thinker, not speaking for the GNU Project References: <36cf0c78-76ac-40e0-87fd-1c73506ba516@gmail.com> Date: Fri, 08 Dec 2023 23:18:22 -0300 In-Reply-To: <36cf0c78-76ac-40e0-87fd-1c73506ba516@gmail.com> (Jeff Law's message of "Thu, 7 Dec 2023 17:28:55 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_STATUS,KAM_NUMSUBJECT,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello, Jeff, DJ, Thanks for the info. On Dec 7, 2023, Jeff Law wrote: > On 12/6/23 15:03, DJ Delorie wrote: >> Alexandre Oliva 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