public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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

> 

      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).