public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Jeff Law <jeffreyalaw@gmail.com>
Cc: Lehua Ding <lehua.ding@rivai.ai>,
	 gcc-patches@gcc.gnu.org,  vmakarov@redhat.com,
	 juzhe.zhong@rivai.ai
Subject: Re: [PATCH 0/7] ira/lra: Support subreg coalesce
Date: Sat, 11 Nov 2023 15:33:16 +0000	[thread overview]
Message-ID: <mptbkc02tkz.fsf@arm.com> (raw)
In-Reply-To: <3d6ec0ee-6542-4b6a-a2cd-7fd54c136af9@gmail.com> (Jeff Law's message of "Wed, 8 Nov 2023 12:13:45 -0700")

Jeff Law <jeffreyalaw@gmail.com> writes:
> On 11/8/23 02:40, Richard Sandiford wrote:
>> Lehua Ding <lehua.ding@rivai.ai> writes:
>>> Hi,
>>>
>>> These patchs try to support subreg coalesce feature in
>>> register allocation passes (ira and lra).
>> 
>> Thanks a lot for the series.  This is definitely something we've
>> needed for a while.
>> 
>> I probably won't be able to look at it in detail for a couple of weeks
>> (and the real review should come from Vlad anyway), but one initial
>> comment:
> Absolutely agreed on the above.
>
> The other thing to ponder.  Jivan and I have been banging on Joern's 
> sub-object tracking bits for a totally different problem in the RISC-V 
> space.  But there may be some overlap.
>
> Essentially Joern's code tracks liveness for a few chunks in registers. 
> bits 0..7, bits 8..15, bits 16..31 and bits 32..63.  This includes 
> propagating liveness from the destination through to the sources.  SO 
> for example if we have
>
> (set (reg:SI dest) (plus:SI (srcreg1:SI) (srcreg2:SI)))
>
> If we had previously determined that only bits 0..15 were live in DEST, 
> then we'll propagate that into the source registers.
>
> The goal is to ultimately transform something like
>
> (set (dest:mode) (any_extend:mode (reg:narrower_mode)))
>
> into
>
> (set (dest:mode) (subreg:mode (reg:narrower_mode)))
>
> Where the latter typically will get simplified and propagated away.
>
>
> Joern's code is a bit of a mess, but Jivan and I are slowly untangling 
> it from a correctness standpoint.  It'll also need the usual cleanups.

Ah, nice!  How configurable are the bit ranges?  We might be able to use
something similar to track lanes in a vector operation, to detect the
dead code in:

   ins v0.b[4], w0
   ...
   ins v0.b[4], w1

It sounds like the bit ranges you have now would do that for some
common/useful cases, even if it doesn't handle the general case.

Maybe dead lanes are better tracked at the gimple level though, not sure.
(But AArch64 might need to lower lane operations more than it does now if
we want gimple to handle it.)

Richard

  parent reply	other threads:[~2023-11-11 15:33 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-08  3:47 Lehua Ding
2023-11-08  3:47 ` [PATCH 1/7] ira: Refactor the handling of register conflicts to make it more general Lehua Ding
2023-11-08  7:57   ` Richard Biener
2023-11-08  8:34     ` Lehua Ding
2023-11-08  3:47 ` [PATCH 2/7] ira: Add live_subreg problem and apply to ira pass Lehua Ding
2023-11-08  3:47 ` [PATCH 3/7] ira: Support subreg live range track Lehua Ding
2023-11-08  3:47 ` [PATCH 4/7] ira: Support subreg copy Lehua Ding
2023-11-08  3:47 ` [PATCH 5/7] ira: Add all nregs >= 2 pseudos to tracke subreg list Lehua Ding
2023-11-08  3:47 ` [PATCH 6/7] lra: Apply live_subreg df_problem to lra pass Lehua Ding
2023-11-08  3:47 ` [PATCH 7/7] lra: Support subreg live range track and conflict detect Lehua Ding
2023-11-08  3:55 ` [PATCH 0/7] ira/lra: Support subreg coalesce juzhe.zhong
2023-11-10  9:29   ` Lehua Ding
2023-11-08  9:40 ` Richard Sandiford
2023-11-08 19:13   ` Jeff Law
2023-11-10  9:43     ` Lehua Ding
2023-11-11 15:33     ` Richard Sandiford [this message]
2023-11-11 17:46       ` Jeff Law
2023-11-12  1:16       ` 钟居哲
2023-11-12 11:53         ` Richard Sandiford
2023-11-13  1:11           ` juzhe.zhong
2023-11-13  3:34             ` Lehua Ding
2023-11-10  9:26   ` Lehua Ding
2023-11-10 10:16     ` Richard Sandiford
2023-11-10 10:30       ` Lehua Ding
2023-11-10 10:39         ` Richard Sandiford
2023-11-10 14:28           ` Jeff Law
2023-11-08 16:56 ` Dimitar Dimitrov
2023-11-10  8:46   ` Lehua Ding
2023-11-10  8:53     ` Lehua Ding
2023-11-10 16:00       ` Dimitar Dimitrov
2023-11-12  6:06         ` Lehua Ding
2023-11-12 10:08   ` Lehua Ding
2023-11-09 20:24 ` Vladimir Makarov
2023-11-10  7:59   ` Richard Biener
2023-11-12 12:01   ` Lehua Ding
2023-11-12 12:12     ` Lehua Ding
2023-11-13 19:25     ` Vladimir Makarov

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=mptbkc02tkz.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=juzhe.zhong@rivai.ai \
    --cc=lehua.ding@rivai.ai \
    --cc=vmakarov@redhat.com \
    /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).