public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Vladimir Makarov <vmakarov@redhat.com>
To: Lehua Ding <lehua.ding@rivai.ai>, gcc-patches@gcc.gnu.org
Cc: richard.sandiford@arm.com, juzhe.zhong@rivai.ai
Subject: Re: [PATCH V3 1/7] df: Add DF_LIVE_SUBREG problem
Date: Mon, 13 Nov 2023 17:38:36 -0500	[thread overview]
Message-ID: <040fba3b-4f8d-f8cf-df7a-5b77ac251148@redhat.com> (raw)
In-Reply-To: <20231112120817.2635864-2-lehua.ding@rivai.ai>


On 11/12/23 07:08, Lehua Ding wrote:
> This patch adds a live_subreg problem to extend the original live_reg to
> track the liveness of subreg. We will only try to trace speudo registers
> who's mode size is a multiple of nature size and eventually a small portion
> of the inside will appear to use subreg. With live_reg problem, live_subreg
> prbolem will have the following output. full_in/out mean the entire pesudo
> live in/out, partial_in/out mean the subregs of the pesudo are live in/out,
> and range_in/out indicates which part of the pesudo is live. all_in/out is
> the union of full_in/out and partial_in/out:
>
I am not a maintainer or reviewer of data-flow analysis framework and 
can not approve this patch except changes in regs.h.  Richard Sandiford 
or Jeff Law as global reviewers probably can do this.

As for regs.h changes, they are ok for me after fixing general issues I 
mentioned in my previous email (two spaces after sentence ends in the 
comments).

I think all this code is a major compiler time and memory consumer in 
all set of the patches.  DF analysis is slow by itself even when only 
effective data structures as bitmaps are used but you are introducing 
even slower data structure as maps (I believe better performance data 
structure can be used instead).  In the very first version of LRA I used 
DFA but it made LRA so slow that I had to introduce own data structures 
which are faster in case of massive RTL changes in LRA.  The same 
problem exists for using generic C++ standard library data as vectors 
and maps for critical code.  It is hard to get a needed performance when 
the exact implementation can vary or be not what you need, e.g. vector 
initial capacity, growth etc.  But again the performance issues can be 
addressed later.



  reply	other threads:[~2023-11-13 22:38 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-12 12:08 [PATCH V3 0/7] ira/lra: Support subreg coalesce Lehua Ding
2023-11-12 12:08 ` [PATCH V3 1/7] df: Add DF_LIVE_SUBREG problem Lehua Ding
2023-11-13 22:38   ` Vladimir Makarov [this message]
2023-11-14  8:14     ` Richard Biener
2023-11-14  8:38       ` Lehua Ding
2023-11-14  9:03         ` Richard Biener
2023-11-14 14:52           ` Vladimir Makarov
2023-11-14 17:18         ` Vladimir Makarov
2023-11-14 18:29           ` Vladimir Makarov
2023-11-20 20:11   ` Richard Sandiford
2023-11-21  6:35     ` Lehua Ding
2023-11-12 12:08 ` [PATCH V3 2/7] ira: Switch to live_subreg data Lehua Ding
2023-11-14 20:26   ` Vladimir Makarov
2023-11-12 12:08 ` [PATCH V3 3/7] ira: Support subreg live range track Lehua Ding
2023-11-14 20:37   ` Vladimir Makarov
2023-11-12 12:08 ` [PATCH V3 4/7] ira: Support subreg copy Lehua Ding
2023-11-16 21:13   ` Vladimir Makarov
2023-11-17  2:06     ` Lehua Ding
2023-11-17 14:05       ` Vladimir Makarov
2023-11-18  8:00         ` Lehua Ding
2023-11-18  8:06           ` Sam James
2023-11-18  8:16             ` Lehua Ding
2023-11-18  8:24               ` Sam James
2023-11-18  8:27                 ` Lehua Ding
2023-11-12 12:08 ` [PATCH V3 5/7] ira: Add all nregs >= 2 pseudos to tracke subreg list Lehua Ding
2023-11-16 21:14   ` Vladimir Makarov
2023-11-12 12:08 ` [PATCH V3 6/7] lra: Switch to live_subreg data flow Lehua Ding
2023-11-12 12:08 ` [PATCH V3 7/7] lra: Support subreg live range track and conflict detect Lehua Ding
2023-11-13 16:43 ` [PATCH V3 0/7] ira/lra: Support subreg coalesce Dimitar Dimitrov
2023-11-15  2:10   ` Lehua Ding
2023-11-13 19:37 ` Vladimir Makarov
2023-11-14  5:37   ` Lehua Ding
2023-11-14 23:33     ` Peter Bergner
2023-11-14 23:22 ` Peter Bergner
2023-11-15  3:12   ` Lehua Ding
2023-11-15  3:33     ` Peter Bergner

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=040fba3b-4f8d-f8cf-df7a-5b77ac251148@redhat.com \
    --to=vmakarov@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=juzhe.zhong@rivai.ai \
    --cc=lehua.ding@rivai.ai \
    --cc=richard.sandiford@arm.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).