From: Richard Sandiford <richard.sandiford@arm.com>
To: "H.J. Lu via Gcc-patches" <gcc-patches@gcc.gnu.org>
Cc: Richard Biener <richard.guenther@gmail.com>,
Uros Bizjak <ubizjak@gmail.com>,
Bernd Edlinger <bernd.edlinger@hotmail.de>,
"H.J. Lu" <hjl.tools@gmail.com>, Jeff Law <jlaw@tachyum.com>
Subject: Re: [PATCH v2] Add vec_const_duplicate optab and TARGET_GEN_MEMSET_SCRATCH_RTX
Date: Tue, 01 Jun 2021 06:50:58 +0100 [thread overview]
Message-ID: <mpt1r9myvy5.fsf@arm.com> (raw)
In-Reply-To: <YLVFiD5lvkSORSmz@gmail.com> (H. J. Lu via Gcc-patches's message of "Mon, 31 May 2021 13:22:32 -0700")
"H.J. Lu via Gcc-patches" <gcc-patches@gcc.gnu.org> writes:
> On Mon, May 31, 2021 at 06:32:04AM -0700, H.J. Lu wrote:
>> On Mon, May 31, 2021 at 6:26 AM Richard Biener
>> <richard.guenther@gmail.com> wrote:
>> >
>> > On Mon, May 31, 2021 at 3:12 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>> > >
>> > > On Mon, May 31, 2021 at 5:46 AM Richard Biener
>> > > <richard.guenther@gmail.com> wrote:
>> > > >
>> > > > On Mon, May 31, 2021 at 2:09 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>> > > > >
>> > > > > On Wed, May 26, 2021 at 10:28:16AM +0200, Richard Biener wrote:
>> > > > > > > > >
>> > > > > > > > > -- Target Hook: rtx TARGET_GEN_MEMSET_VALUE (rtx DATA, scalar_int_mode
>> > > > > > > > > MODE)
>> > > > > > > > > This function returns the RTL of a register containing
>> > > > > > > > > 'GET_MODE_SIZE (MODE)' consecutive copies of the unsigned char
>> > > > > > > > > value given in the RTL register DATA. For example, if MODE is 4
>> > > > > > > > > bytes wide, return the RTL for 0x01010101*DATA.
>> > > > > > > >
>> > > > > > > > For this one I wonder if it should be an optab instead. Couldn't you
>> > > > > > > > use the existing vec_duplicate for this by using (paradoxical) subregs
>> > > > > > > > like (subreg:TI (vec_duplicate:VnQI (subreg:VnQI (reg:QI ...)))?
>> > > > > > >
>> > > > > > > I tried. It doesn't even work on x86. See:
>> > > > > > >
>> > > > > > > https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570661.html
>> > > > > >
>> > > > > > Not sure what I should read from there...
>> > > > > >
>> > > > > > > There are special cases to subreg HI, SI and DI modes of TI mode in
>> > > > > > > ix86_gen_memset_value_from_prev. simplify_gen_subreg doesn't
>> > > > > > > work here. Each backend may need its own special handling.
>> > > > > >
>> > > > > > OK, I guess I'm not (RTL) qualified enough to further review these parts,
>> > > > > > sorry. Since we're doing code generation the canonical way to communicate
>> > > > > > with backends should be optabs, not some set of disconnected target hooks.
>> > > > > > But as said, I probably don't know enough of RTL to see why it's the only way.
>> > > > > >
>> > > > > > Richard.
>> > > > >
>> > > > > Here is the patch to add optabs instead. Does it look OK?
>> > > > >
>> > > > > Thanks.
>> > > > >
>> > > > > H.J.
>> > > > > ---
>> > > > > Add 2 optabs:
>> > > > >
>> > > > > 1. integer_extract: Extract lower bit value from the integer value in
>> > > > > TImode, OImode or XImode.
>> > > >
>> > > > That sounds very specific, esp. the restriction to {TI,OI,XI}mode.
>> > > > It also sounds like it matches (subreg:{TI,OI,XI} (...) 0). There are
>> > > > existing target hooks verifying subreg validity - why's that not a good
>> > > > fit here? ISTR you say gen_lowpart () doesn't work (or was it
>> > > > simplify_gen_subreg?), why's that so?
>> > >
>> > > {TI,OI,XI}mode are storage only integer types. subreg doesn't work
>> > > well on them. I got
>> > >
>> > > [hjl@gnu-cfl-2 pieces]$ cat s2.i
>> > > extern void *ops;
>> > >
>> > > void
>> > > foo (int c)
>> > > {
>> > > __builtin_memset (ops, c, 34);
>> > > }
>> > > [hjl@gnu-cfl-2 pieces]$ make s2.s
>> > > /export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
>> > > -B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/
>> > > -O2 -march=haswell -S s2.i
>> > > during RTL pass: reload
>> > > s2.i: In function ‘foo’:
>> > > s2.i:7:1: internal compiler error: maximum number of generated reload
>> > > insns per insn achieved (90)
>> > > 7 | }
>> > > | ^
>> > > 0x1050734 lra_constraints(bool)
>> > > /export/gnu/import/git/gitlab/x86-gcc/gcc/lra-constraints.c:5091
>> > > 0x1039536 lra(_IO_FILE*)
>> > > /export/gnu/import/git/gitlab/x86-gcc/gcc/lra.c:2336
>> > > 0xfe1140 do_reload
>> > > /export/gnu/import/git/gitlab/x86-gcc/gcc/ira.c:5822
>> > > 0xfe162e execute
>> > > /export/gnu/import/git/gitlab/x86-gcc/gcc/ira.c:6008
>> > > Please submit a full bug report,
>> > > with preprocessed source if appropriate.
>> > > Please include the complete backtrace with any bug report.
>> > > See <https://gcc.gnu.org/bugs/> for instructions.
>> > > make: *** [Makefile:32: s2.s] Error 1
>> > > [hjl@gnu-cfl-2 pieces]$
>> > >
>> > > due to
>> > >
>> > > (insn 12 11 0 (set (mem:HI (plus:DI (reg/f:DI 84)
>> > > (const_int 32 [0x20])) [0 MEM <char[1:34]> [(void
>> > > *)ops.0_1]+32 S2 A8])
>> > > (subreg:HI (reg:OI 51 xmm15) 0)) "s2.i":6:3 -1
>> > > (nil))
>> > >
>> > > The new optab gives us
>> > >
>> > > (insn 12 11 13 2 (set (reg:TI 88)
>> > > (reg:TI 51 xmm15)) "s2.i":6:3 -1
>> > > (nil))
>> > > (insn 13 12 14 2 (set (reg:SI 89)
>> > > (subreg:SI (reg:TI 88) 0)) "s2.i":6:3 -1
>> > > (nil))
>> > > (insn 14 13 15 2 (set (reg:HI 87)
>> > > (subreg:HI (reg:SI 89) 0)) "s2.i":6:3 -1
>> > > (nil))
>> >
>> > that looks odd to me - what's the final result after LRA? I think
>>
>> I got:
>>
>> vmovd %edi, %xmm15
>> movq ops(%rip), %rdx
>> vpbroadcastb %xmm15, %ymm15
>> vmovq %xmm15, %rax <<<< move to GPR
>> vmovdqu %ymm15, (%rdx)
>> movw %ax, 32(%rdx) <<<< subreg of GPR
>> vzeroupper
>> ret
>>
>> > we should see to make lowpart_subreg work on {XI,OI,TI}mode.
>> > Only two steps should be necessary at most:
>> > xmm -> gpr, grp -> subreg, or gpr -> subreg. So the expander
>> > code in memset should try to generate the subreg directly
>>
>> subreg didn't fail on x86 when I tried.
>>
>> > and if that fails, try a word_mode subreg followed by the subreg.
>>
>> I will try word_mode subreg.
>>
>
> Here is the v2 patch to use word_mode subreg. For
>
> ---
> extern void *ops;
>
> void
> foo (int c)
> {
> __builtin_memset (ops, 4, 32);
> }
> ---
>
> without vec_const_duplicate, I got
>
> movl $4, %eax
> movq ops(%rip), %rdx
> movd %eax, %xmm0
> punpcklbw %xmm0, %xmm0
> punpcklwd %xmm0, %xmm0
> pshufd $0, %xmm0, %xmm0
> movups %xmm0, (%rdx)
> movups %xmm0, 16(%rdx)
> ret
>
> With vec_const_duplicate, I got
>
> movq ops(%rip), %rax
> movdqa .LC0(%rip), %xmm0
> movups %xmm0, (%rax)
> movups %xmm0, 16(%rax)
> ret
>
> If vec_duplicate is allowed to fail, I don't need vec_const_duplicate.
I don't understand why we need an optab for this though. If the operand
is constant then we should just be doing an ordinary move in which the
source is a CONST_VECTOR. It's then up to the move patterns to handle
duplicated constants as efficiently as possible. (Sorry if this was
discussed upthread and I missed it.)
Thanks,
Richard
next prev parent reply other threads:[~2021-06-01 5:51 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-18 19:16 [PATCH v4 00/12] Allow TImode/OImode/XImode in op_by_pieces operations H.J. Lu
2021-05-18 19:16 ` [PATCH v4 01/12] Add TARGET_READ_MEMSET_VALUE/TARGET_GEN_MEMSET_VALUE H.J. Lu
2021-05-19 9:25 ` Richard Biener
2021-05-19 12:55 ` H.J. Lu
2021-05-20 20:49 ` [PATCH] Add 3 target hooks for memset H.J. Lu
2021-05-21 5:42 ` Bernd Edlinger
2021-05-21 11:53 ` H.J. Lu
2021-05-25 14:34 ` Richard Biener
2021-05-25 15:11 ` H.J. Lu
2021-05-26 8:28 ` Richard Biener
2021-05-31 12:09 ` [PATCH] Add integer_extract and vec_const_duplicate optabs H.J. Lu
2021-05-31 12:46 ` Richard Biener
2021-05-31 13:12 ` H.J. Lu
2021-05-31 13:25 ` Richard Biener
2021-05-31 13:32 ` H.J. Lu
2021-05-31 13:36 ` H.J. Lu
2021-05-31 20:22 ` [PATCH v2] Add vec_const_duplicate optab and TARGET_GEN_MEMSET_SCRATCH_RTX H.J. Lu
2021-06-01 5:50 ` Richard Sandiford [this message]
2021-06-01 5:54 ` Jeff Law
2021-06-01 13:05 ` H.J. Lu
2021-06-01 13:25 ` Richard Biener
2021-06-01 13:29 ` H.J. Lu
2021-06-01 14:21 ` Jeff Law
2021-06-01 23:07 ` H.J. Lu
2021-06-02 1:21 ` Hongtao Liu
2021-06-02 1:54 ` H.J. Lu
2021-06-02 7:02 ` Richard Biener
2021-06-02 13:50 ` H.J. Lu
2021-05-18 19:16 ` [PATCH v4 02/12] x86: Add TARGET_READ_MEMSET_VALUE/TARGET_GEN_MEMSET_VALUE H.J. Lu
2021-05-18 19:16 ` [PATCH v4 03/12] x86: Avoid stack realignment when copying data H.J. Lu
2021-05-18 19:16 ` [PATCH v4 04/12] Remove MAX_BITSIZE_MODE_ANY_INT H.J. Lu
2021-05-25 14:37 ` Richard Biener
2021-05-18 19:16 ` [PATCH v4 05/12] x86: Update piecewise move and store H.J. Lu
2021-05-18 19:16 ` [PATCH v4 06/12] x86: Add AVX2 tests for PR middle-end/90773 H.J. Lu
2021-05-18 19:16 ` [PATCH v4 07/12] x86: Add tests for piecewise move and store H.J. Lu
2021-05-18 19:16 ` [PATCH v4 08/12] x86: Also pass -mno-avx to pr72839.c H.J. Lu
2021-05-18 19:16 ` [PATCH v4 09/12] x86: Also pass -mno-avx to cold-attribute-1.c H.J. Lu
2021-05-18 19:16 ` [PATCH v4 10/12] x86: Also pass -mno-avx to sw-1.c for ia32 H.J. Lu
2021-05-18 19:16 ` [PATCH v4 11/12] x86: Update gcc.target/i386/incoming-11.c H.J. Lu
2021-05-18 19:16 ` [PATCH v4 12/12] constructor: Check if it is faster to load constant from memory H.J. Lu
2021-05-19 9:33 ` Richard Biener
2021-05-19 13:22 ` H.J. Lu
2021-05-19 13:27 ` Bernd Edlinger
2021-05-19 19:04 ` H.J. Lu
2021-05-20 6:57 ` Richard Biener
2021-05-20 7:51 ` Richard Biener
2021-05-20 14:03 ` [PATCH] constructor: Elide expand_constructor when can move by pieces is true H.J. Lu
2021-05-21 5:35 ` Bernd Edlinger
2021-05-21 6:57 ` Richard Biener
2021-05-21 7:30 ` Bernd Edlinger
2021-05-21 13:13 ` H.J. Lu
2021-05-21 13:09 ` [PATCH] Elide expand_constructor if move by pieces is preferred H.J. Lu
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=mpt1r9myvy5.fsf@arm.com \
--to=richard.sandiford@arm.com \
--cc=bernd.edlinger@hotmail.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=hjl.tools@gmail.com \
--cc=jlaw@tachyum.com \
--cc=richard.guenther@gmail.com \
--cc=ubizjak@gmail.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).