On Tue, Jun 1, 2021 at 7:21 AM Jeff Law <jeffreya...@gmail.com> wrote:
>
>
>
> On 6/1/2021 7:29 AM, H.J. Lu via Gcc-patches wrote:
> > On Tue, Jun 1, 2021 at 6:25 AM Richard Biener
> > <richard.guent...@gmail.com> wrote:
> >> On Tue, Jun 1, 2021 at 3:05 PM H.J. Lu <hjl.to...@gmail.com> wrote:
> >>> On Mon, May 31, 2021 at 11:54:53PM -0600, Jeff Law wrote:
> >>>>
> >>>> On 5/31/2021 11:50 PM, Richard Sandiford wrote:
> >>>>> "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.guent...@gmail.com> wrote:
> >>>>>>>> On Mon, May 31, 2021 at 3:12 PM H.J. Lu <hjl.to...@gmail.com> wrote:
> >>>>>>>>> On Mon, May 31, 2021 at 5:46 AM Richard Biener
> >>>>>>>>> <richard.guent...@gmail.com> wrote:
> >>>>>>>>>> On Mon, May 31, 2021 at 2:09 PM H.J. Lu <hjl.to...@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.)
> >>>> That's exactly the point I'm trying to get across as well.
> >>>>
> >>> This is what we do today. But I'd like to generate
> >>>
> >>> movl $4, %eax
> >>> vpbroadcastb %eax, %ymm15
> >>> movq ops(%rip), %rax
> >>> vmovdqu %ymm15, (%rax)
> >>> vzeroupper
> >>> ret
> >>>
> >>> instead of
> >>>
> >>> vmovdqa .LC0(%rip), %ymm15
> >>> movq ops(%rip), %rax
> >>> vmovdqu %ymm15, (%rax)
> >>> vzeroupper
> >>> ret
> >>>
> >>> Do I need a vec_dup pattern for it?
> >> I think we have special code sequences to materialize some
> >> constant vectors already, we should be able to add to that, no?
> > We can do that for all 0s and all 1s at the final codegen. For
> > other values, since we need a GPR, we can't do that.
> You can catch them in your movxx expanders, you can create peep2
> patterns that use available GPRs, etc. I don't see a fundamental need
> to to introduce new target macros or hooks to handle this stuff. In
> fact I've done both to handle a closely related issue on our port.
>
One problem of expanding TI/OI/XI moves to broadcast is that other
RTL passes may change it. For example, expander generates:
(insn 7 5 6 (set (reg:QI 85)
(const_int 12 [0xc]))
"/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gcc.target/i386/pr90773-17.c":9:3
-1
(nil))
(insn 6 7 8 (set (reg:V16QI 84)
(vec_duplicate:V16QI (reg:QI 85)))
"/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gcc.target/i386/pr90773-17.c
":9:3 5103 {*avx512vl_vec_dup_gprv16qi}
(nil))
(insn 8 6 9 (set (subreg:V16QI (reg:TI 86) 0)
(reg:V16QI 84))
"/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gcc.target/i386/pr90773-17.c":9:3
-1
(nil))
(insn 9 8 10 (set (mem:TI (reg/f:DI 83) [0 MEM <char[1:19]> [(void
*)dst.0_1]+0 S16 A8])
(reg:TI 86))
"/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gcc.target/i386/pr90773-17.c":9:3
-1
(nil))
combine turns it into:
insn 9 6 10 2 (set (mem:TI (reg/f:DI 83 [ dst ]) [0 MEM <char[1:19]>
[(void *)dst.0_1]+0 S16 A8])
(const_wide_int 0xc0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c))
"/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gcc.target/
i386/pr90773-17.c":9:3 73 {*movti_internal}
(nil))
LRA tries:
(insn 14 15 16 2 (set (reg:V16QI 20 xmm0 [89])
(vec_duplicate:V16QI (reg:QI 4 si [90])))
"/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gcc.target/i386/pr907
73-17.c":9:3 5103 {*avx512vl_vec_dup_gprv16qi}
(nil))
(insn 16 14 9 2 (set (reg:V16QI 1 dx)
(reg:V16QI 20 xmm0 [89]))
"/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gcc.target/i386/pr90773-17.c":9:3
152
7 {movv16qi_internal}
(nil))
(insn 9 16 10 2 (set (mem:TI (reg/f:DI 0 ax [orig:83 dst ] [83]) [0
MEM <char[1:19]> [(void *)dst.0_1]+0 S16 A8])
(reg:TI 1 dx [88]))
"/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gcc.target/i386/pr90773-17.c":9:3
73 {*movt
i_internal}
and fails:
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gcc.target/i386/pr90773-17.c:
In function ‘foo’:
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gcc.target/i386/pr90773-17.c:10:1:
error: insn does not satisfy its constraints:
(insn 16 14 9 2 (set (reg:V16QI 1 dx)
(reg:V16QI 20 xmm0 [89]))
"/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gcc.target/i386/pr90773-17.c":9:3
1527 {movv16qi_internal}
(nil))
I want to hide
(const_wide_int 0xc0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c)
from RTL passes.
--
H.J.
