From: Richard Biener <rguenther@suse.de>
To: Jiufu Guo <guojiufu@linux.ibm.com>
Cc: Richard Biener <richard.guenther@gmail.com>,
Jeff Law <jeffreyalaw@gmail.com>,
gcc-patches@gcc.gnu.org, pinskia@gcc.gnu.org, dje.gcc@gmail.com,
linkw@gcc.gnu.org, segher@kernel.crashing.org,
rguenth@gcc.gnu.org
Subject: Re: [RFC] propgation leap over memory copy for struct
Date: Wed, 9 Nov 2022 12:56:49 +0000 (UTC) [thread overview]
Message-ID: <nycvar.YFH.7.77.849.2211091255240.4294@jbgna.fhfr.qr> (raw)
In-Reply-To: <7e8rkktrdz.fsf@pike.rch.stglabs.ibm.com>
On Wed, 9 Nov 2022, Jiufu Guo wrote:
> Hi,
>
> Richard Biener <richard.guenther@gmail.com> writes:
>
> > On Mon, Oct 31, 2022 at 11:14 PM Jeff Law via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> >>
> >>
> >> On 10/30/22 20:42, Jiufu Guo via Gcc-patches wrote:
> >> > Hi,
> >> >
> >> > We know that for struct variable assignment, memory copy may be used.
> >> > And for memcpy, we may load and store more bytes as possible at one time.
> >> > While it may be not best here:
> >> > 1. Before/after stuct variable assignment, the vaiable may be operated.
> >> > And it is hard for some optimizations to leap over memcpy. Then some struct
> >> > operations may be sub-optimimal. Like the issue in PR65421.
> >> > 2. The size of struct is constant mostly, the memcpy would be expanded. Using
> >> > small size to load/store and executing in parallel may not slower than using
> >> > large size to loat/store. (sure, more registers may be used for smaller bytes.)
> >> >
> >> >
> >> > In PR65421, For source code as below:
> >> > ////////t.c
> >> > #define FN 4
> >> > typedef struct { double a[FN]; } A;
> >> >
> >> > A foo (const A *a) { return *a; }
> >> > A bar (const A a) { return a; }
> >>
> >> So the first question in my mind is can we do better at the gimple
> >> phase? For the second case in particular can't we just "return a"
> >> rather than copying a into <retval> then returning <retval>? This feels
> >> a lot like the return value optimization from C++. I'm not sure if it
> >> applies to the first case or not, it's been a long time since I looked
> >> at NRV optimizations, but it might be worth poking around in there a bit
> >> (tree-nrv.cc).
> >>
> >>
> >> But even so, these kinds of things are still bound to happen, so it's
> >> probably worth thinking about if we can do better in RTL as well.
> >>
> >>
> >> The first thing that comes to my mind is to annotate memcpy calls that
> >> are structure assignments. The idea here is that we may want to expand
> >> a memcpy differently in those cases. Changing how we expand an opaque
> >> memcpy call is unlikely to be beneficial in most cases. But changing
> >> how we expand a structure copy may be beneficial by exposing the
> >> underlying field values. This would roughly correspond to your method #1.
> >>
> >> Or instead of changing how we expand, teach the optimizers about these
> >> annotated memcpy calls -- they're just a a copy of each field. That's
> >> how CSE and the propagators could treat them. After some point we'd
> >> lower them in the usual ways, but at least early in the RTL pipeline we
> >> could keep them as annotated memcpy calls. This roughly corresponds to
> >> your second suggestion.
> >
> > In the end it depends on the access patterns so some analysis like SRA
> > performs would be nice. The issue with expanding memcpy on GIMPLE
> > is that we currently cannot express 'rep; movb;' or other target specific
> > sequences from the cpymem like optabs on GIMPLE and recovering those
> > from piecewise copies on RTL is going to be difficult.
> Actually, it is a special memcpy. It is generated during expanding the
> struct assignment(expand_assignment/store_expr/emit_block_move).
> We may introduce a function block_move_for_record for struct type. And
> this function could be a target hook to generate specificed sequences.
> For example:
> r125:DF=[r112:DI+0x20]
> r126:DF=[r112:DI+0x28]
> [r112:DI]=r125:DF
> [r112:DI+0x8]=r126:DF
>
> After expanding, following passes(cse/prop/dse/..) could optimize the
> insn sequences. e.g "[r112:DI+0x20]=f1;r125:DF=[r112:DI+0x20];
> [r112:DI]=r125:DF;r129:DF=[r112:DI]" ==> "r129:DF=f1"
>
> And if the small reading/writing insns are still occur in late passes
> e.g. combine, we would recover the isnsn to better sequence:
> r125:DF=[r112:DI+0x20];r126:DF=[r112:DI+0x28]
> ==>
> r155:V2DI=[r112:DI+0x20];
>
> Any comments? Thanks!
As said the best copying decomposition depends on the followup uses
and the argument passing ABI which is why I suggested to perform
SRA like analysis which collects the access patterns and use that
to drive the heuristic expanding this special memcpy.
Richard.
next prev parent reply other threads:[~2022-11-09 12:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-31 2:42 Jiufu Guo
2022-10-31 22:13 ` Jeff Law
2022-11-01 0:49 ` Segher Boessenkool
2022-11-01 4:30 ` Jiufu Guo
2022-11-05 14:13 ` Richard Biener
2022-11-08 4:05 ` Jiufu Guo
2022-11-09 7:51 ` Jiufu Guo
2022-11-09 8:50 ` Richard Biener
2022-11-01 3:30 ` Jiufu Guo
2022-11-05 11:38 ` Richard Biener
2022-11-09 9:21 ` Jiufu Guo
2022-11-09 12:56 ` Richard Biener [this message]
2022-11-01 0:37 ` Segher Boessenkool
2022-11-01 3:01 ` Jiufu Guo
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=nycvar.YFH.7.77.849.2211091255240.4294@jbgna.fhfr.qr \
--to=rguenther@suse.de \
--cc=dje.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=guojiufu@linux.ibm.com \
--cc=jeffreyalaw@gmail.com \
--cc=linkw@gcc.gnu.org \
--cc=pinskia@gcc.gnu.org \
--cc=rguenth@gcc.gnu.org \
--cc=richard.guenther@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).