From: Jiufu Guo <guojiufu@linux.ibm.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: 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, 09 Nov 2022 17:21:28 +0800 [thread overview]
Message-ID: <7e8rkktrdz.fsf@pike.rch.stglabs.ibm.com> (raw)
In-Reply-To: <CAFiYyc1gtCSC5563LAWDGEn1EAcbpkcCqjj5JMEqnRyKMTmr6Q@mail.gmail.com> (Richard Biener's message of "Sat, 5 Nov 2022 12:38:11 +0100")
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!
BR,
Jeff(Jiufu)
>
>>
>> jeff
>>
>>
>>
next prev parent reply other threads:[~2022-11-09 9:21 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 [this message]
2022-11-09 12:56 ` Richard Biener
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=7e8rkktrdz.fsf@pike.rch.stglabs.ibm.com \
--to=guojiufu@linux.ibm.com \
--cc=dje.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--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).