From: "Koning, Paul" <Paul.Koning@dell.com>
To: Jeff Law <jeffreyalaw@gmail.com>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Always enable LRA
Date: Fri, 14 Oct 2022 19:58:39 +0000 [thread overview]
Message-ID: <64E0D774-6501-4AD7-8F2A-9AD18CF36CB0@dell.com> (raw)
In-Reply-To: <7b04be7e-d27d-0099-6631-6a764aed2cd7@gmail.com>
> On Oct 14, 2022, at 2:03 PM, Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>
>
> On 10/14/22 11:35, Segher Boessenkool wrote:
>> On Fri, Oct 14, 2022 at 11:07:43AM -0600, Jeff Law wrote:
>>>> LRA only ever generates insns that pass recog. The backend allows this
>>>> define_insn, requiring it to be split (it returns template "#"), but
>>>> then somehow it doesn't match in any split pass?
>>> Nope. The elimination code will just change one register without
>>> re-recognizing. That's precisely what happens here.
>> That is a big oversight then. Please file a PR?
>
> Sure. But just recognizing (for this particular case) will just move the fault from a failure to split to a failure to recognize. From my wanderings in the elimination code, I don't see that it has a path that would allow it to reasonably handle this case -- ie, if the insn does not recognize, what then? Conceptually we need to generate an input-reload but I don't see a way to do that in the elimination code. Maybe Vlad knows how it ought to be handled.
I probably have too simplistic a view of this, but the way I think of it is that LRA (and reload) make decisions subject to constraints, and among those constraints are the ones specified in the MD file patterns. That to me means that a substitution proposed to be made by the LRA code is subject to those invariants: it can't do that if the constraints say "no" and must then consider some other alternative.
paul
next prev parent reply other threads:[~2022-10-14 19:58 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
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 [this message]
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:
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=64E0D774-6501-4AD7-8F2A-9AD18CF36CB0@dell.com \
--to=paul.koning@dell.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jeffreyalaw@gmail.com \
--cc=segher@kernel.crashing.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).