From: Jeff Law <jeffreyalaw@gmail.com>
To: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] lower-subreg, expr: Mitigate inefficiencies derived from "(clobber (reg X))" followed by "(set (subreg (reg X)) (...))"
Date: Fri, 5 Aug 2022 10:12:19 -0600 [thread overview]
Message-ID: <9e29de32-8547-0f5d-553b-38d7f513613b@gmail.com> (raw)
In-Reply-To: <mptzggkmj83.fsf@arm.com>
On 8/4/2022 3:49 AM, Richard Sandiford via Gcc-patches wrote:
>
>>> TBH I'm surprised we still run init_regs for LRA. I thought there was
>>> a plan to stop doing that, but perhaps I misremember.
>> Sorry I am not sure about the status of LRA... because the xtensa port is still using reload.
> Ah, hadn't realised that. If you have time to work on it, it would be
> really good to move over to LRA. There are plans to remove old reload.
Definitely worth investigating. With the cc0 removal done I think the
last blocker for removing the old reload pass is gone. We just need to
get the remaining targets converted to LRA.
> It might be that old reload *does* treat a pseudo clobber as a conflict.
> I can't remember now. If so, then zeroing the register wouldn't be
> too bad (for old reload only).
No idea anymore either. I'd be a bit surprised since IIRC the main
purpose was to tell the old uninit warning code that the entire object
was set by the subsequent libcall sequence. But all that code is long-gone.
Which I think raises a question. Do we even need those CLOBBERSs anymore?
>
>> As conclusion, trying to tweak the common code side may have been a bit premature.
>> I'll consider if I can deal with those issues on the side of the target-specific code.
> It's likely to be at least partly a target-independent issue, so tweaking
> the common code makes sense in principle.
>
> Does adding !HARD_REGISTER_P (x) to:
>
> /* Show the output dies here. This is necessary for SUBREGs
> of pseudos since we cannot track their lifetimes correctly;
> hard regs shouldn't appear here except as return values. */
> if (!reload_completed && !reload_in_progress
> && REG_P (x) && !reg_overlap_mentioned_p (x, y))
> emit_clobber (x);
>
> in emit_move_complex_parts help? If so, I think we should do at
> least that much.
If we can't remove the CLOBBERs entirely, then this sounds like a good
thing, even if it doesn't help this specific case.
jeff
next prev parent reply other threads:[~2022-08-05 16:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-03 1:35 Takayuki 'January June' Suwa
2022-08-03 7:52 ` Richard Sandiford
2022-08-03 11:17 ` Takayuki 'January June' Suwa
2022-08-04 9:49 ` Richard Sandiford
2022-08-04 12:35 ` Takayuki 'January June' Suwa
2022-08-05 16:20 ` Jeff Law
2022-10-14 11:06 ` [PATCH] xtensa: Prepare the transition from Reload to LRA Takayuki 'January June' Suwa
2022-10-16 5:03 ` Max Filippov
2022-10-18 2:57 ` [PATCH v2] " Takayuki 'January June' Suwa
2022-10-18 3:14 ` Max Filippov
2022-10-18 12:16 ` Max Filippov
2022-10-19 8:16 ` [PATCH v3] " Takayuki 'January June' Suwa
2022-10-19 11:31 ` Max Filippov
2022-10-25 20:09 ` Jan-Benedict Glaw
2022-10-26 3:23 ` Takayuki 'January June' Suwa
2022-10-26 6:27 ` [PATCH] xtensa: Fix out-of-bounds array access Takayuki 'January June' Suwa
2022-10-26 17:05 ` Max Filippov
2022-08-05 16:12 ` Jeff Law [this message]
2022-08-03 17:23 ` [PATCH] lower-subreg, expr: Mitigate inefficiencies derived from "(clobber (reg X))" followed by "(set (subreg (reg X)) (...))" Jeff Law
2022-08-04 9:39 ` Richard Sandiford
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=9e29de32-8547-0f5d-553b-38d7f513613b@gmail.com \
--to=jeffreyalaw@gmail.com \
--cc=gcc-patches@gcc.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).