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

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