From: Jeff Law <jeffreyalaw@gmail.com>
To: Alexandre Oliva <oliva@gnu.org>
Cc: DJ Delorie <dj@redhat.com>, gcc@gcc.gnu.org
Subject: Re: [PATCH] strub: disable on rl78
Date: Sun, 10 Dec 2023 11:27:03 -0700 [thread overview]
Message-ID: <6e354942-bab6-4d31-b466-a068d8c7ce9a@gmail.com> (raw)
In-Reply-To: <or7cloazkh.fsf_-_@lxoliva.fsfla.org>
On 12/8/23 19:18, Alexandre Oliva wrote:
> Hello, Jeff, DJ,
>
> Thanks for the info.
>
> On Dec 7, 2023, Jeff Law <jeffreyalaw@gmail.com> wrote:
>
>> 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.
>
> *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(+)
OK for the trunk. THanks.
jeff
>
prev parent reply other threads:[~2023-12-10 18:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <7afbb6f4-bc43-4dc1-a691-c84b019bbf58@gmail.com>
2023-12-06 21:24 ` strub causing libgcc to fail to build on rl78-elf Alexandre Oliva
2023-12-06 22:03 ` DJ Delorie
2023-12-08 0:28 ` Jeff Law
2023-12-09 2:18 ` [PATCH] strub: disable on rl78 Alexandre Oliva
2023-12-10 18:27 ` Jeff Law [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6e354942-bab6-4d31-b466-a068d8c7ce9a@gmail.com \
--to=jeffreyalaw@gmail.com \
--cc=dj@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=oliva@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).