public inbox for
 help / color / mirror / Atom feed
From: Jeff Law <>
To: "Koning, Paul" <>
Cc: GCC Patches <>
Subject: Re: [PATCH] Always enable LRA
Date: Fri, 14 Oct 2022 08:38:10 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 10/14/22 06:37, Koning, Paul wrote:
>> On Oct 13, 2022, at 9:07 PM, Jeff Law via Gcc-patches <> wrote:
>> On 10/13/22 17:56, Segher Boessenkool wrote:
>>> h8300 fails during GCC build:
>>> /home/segher/src/gcc/libgcc/ In function '_Unwind_SjLj_RaiseException':
>>> /home/segher/src/gcc/libgcc/ error: could not split insn
>>>    141 | }
>>>        | ^
>>> (insn 69 256 327 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [12  S4 A32])
>>>          (reg/f:SI 7 sp)) "/home/segher/src/gcc/libgcc/":118:12 19 {*movsi}
>>>       (expr_list:REG_ARGS_SIZE (const_int 4 [0x4])
>>>          (nil)))
>>> during RTL pass: final
>>> which looks like a backend bug, I don't see a pattern that could split
>>> this (without needing an extra clobber)?
>> I'm aware of this -- its invalid RTL:
>> Uses of the register outside of an address are not permitted within the
>> same insn as a use in an embedded side effect expression because such
>> insns behave differently on different machines and hence must be treated
>> as ambiguous and disallowed.
> I had a bit of a fight with this sort of thing in pdp11, where in fact such operations are executed differently on different machine models.  The solution I picked is to create two sets of machine-specific constraint codes, one for "register N" and the other for "autoinc/dec of any register other than N" and pairing those.  (You can see this in, the mov<mode> definition.)

I've long suspected the pdp11 was the inspiration for this restriction 
(I have memories of noting it before I relocated to Utah, so circa 
1992).  The key problem is the generic parts of the compiler don't know 
what the semantics ought to be -- so it's not obvious when they do a 
substitution whether or not the substitution of one reg for another is 
actually valid.  It's important to remember that sometimes when we 
substitute one register for another, we don't have any contextual 
information about source vs dest -- it's a long standing wart that 
causes problems in other cases as well.

That punts the problem to the backends and the H8 actually tries to deal 
with this restriction.  Basically in the movxx pattern conditions, when 
the destination uses an autoinc addressing mode, the pattern's condition 
will check that the source register is different.  I would expect other 
ports likely to do something similar.

But that approach falls down with reload/lra doing substitutions without 
validating the result.  I guess it might be possible to cobble together 
something with secondary reloads, but it's way way way down on my todo list.

And yes, this case where the autoinc is on the destination works 
consistently on the H8 as well.  We could consider loosening the 
restrictions and let this through.  It's certainly simpler as it's a doc 
change and removing a bit of code on the H8.  It sounds like the pdp11 
already assumes that case is valid.


  reply	other threads:[~2022-10-14 14:38 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-13 23:56 Segher Boessenkool
2022-10-14  0:36 ` Koning, Paul
2022-10-14 16:18   ` Segher Boessenkool
2022-10-14 16:48     ` Koning, Paul
2022-10-14  1:07 ` Jeff Law
2022-10-14 12:37   ` Koning, Paul
2022-10-14 14:38     ` Jeff Law [this message]
2022-10-14 16:37       ` Koning, Paul
2022-10-14 17:10         ` Jeff Law
2022-10-14 17:36           ` Koning, Paul
2022-10-14 21:15             ` Jeff Law
2022-10-14 21:21               ` Koning, Paul
2022-10-14 21:30                 ` Jeff Law
2022-10-15  0:19                 ` Jeff Law
2022-10-14 16:39       ` Richard Biener
2022-10-14 17:11         ` Jeff Law
2022-10-14  4:47 ` Jeff Law
2022-10-14 16:37   ` Segher Boessenkool
2022-10-14 17:07     ` Jeff Law
2022-10-14 17:35       ` Segher Boessenkool
2022-10-14 18:03         ` Jeff Law
2022-10-14 19:58           ` Koning, Paul
2022-10-14 20:12             ` Segher Boessenkool
2022-10-14 20:40               ` Koning, Paul
2022-10-14  6:20 ` Takayuki 'January June' Suwa
2022-10-14 16:25   ` Segher Boessenkool
2022-10-15  3:18     ` Takayuki 'January June' Suwa

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

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