[Bug target/98172] New: Update -mtune=generic for the current Intel and AMD processors

[Bug target/98172] New: Update -mtune=generic for the current Intel and AMD processors

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172

            Bug ID: 98172
           Summary: Update -mtune=generic for the current Intel and AMD
                    processors
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com
                CC: crazylht at gmail dot com
  Target Milestone: ---
            Target: i386,x86-64

-mtune=generic should be updated for the current Intel and AMD processors.

[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
What kind of updates you propose?

[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Target Milestone|---                         |11.0
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-12-07

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jan Hubicka from comment #1)
> What kind of updates you propose?

For one thing, memcpy/memset should be expanded to REP MOVSB/STOSB, never
MOVSL/MOVSQ.

[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, but rep movsb is only fast starting with Zen3 IIRC.

[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172

--- Comment #4 from Jan Hubicka <hubicka at ucw dot cz> ---
> > What kind of updates you propose?
> 
> For one thing, memcpy/memset should be expanded to REP MOVSB/STOSB, never
> MOVSL/MOVSQ.

For core cost tables we use:

/* core_cost should produce code tuned for Core familly of CPUs.  */            
static stringop_algs core_memcpy[2] = {                                         
  {libcall, {{1024, rep_prefix_4_byte, true}, {-1, libcall, false}}},           
  {libcall, {{24, loop, true}, {128, rep_prefix_8_byte, true},                  
             {-1, libcall, false}}}};                                           
static stringop_algs core_memset[2] = {                                         
  {libcall, {{6, loop_1_byte, true},                                            
             {24, loop, true},                                                  
             {8192, rep_prefix_4_byte, true},                                   
             {-1, libcall, false}}},                                            
  {libcall, {{24, loop, true}, {512, rep_prefix_8_byte, true},                  
             {-1, libcall, false}}}};                                           

So we use mosl/modsw for blocks up to 8k in some cases.
What is output of contrib/bench-stringop on later cores?

Honza
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172

--- Comment #5 from Jan Hubicka <hubicka at ucw dot cz> ---
> Hmm, but rep movsb is only fast starting with Zen3 IIRC.
Yep, I think we need to support zen1/2 well. I think we can regress
buldozers somehwat though.

Honza

[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Richard Biener from comment #3)
> Hmm, but rep movsb is only fast starting with Zen3 IIRC.

Are MOVSL/MOVSQ faster than MOVSB on Zen1/Zen2?

[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172

--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
GCC 11 will be system GCC 2 years from now. The current processors in 2020
will be 2 years old.

[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172

--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> ---
-mtune=generic -mavx2 -mfma generates awful code:

[hjl@gnu-skx-1 tmp]$ cat y.c
#define DATA_ENTRIES 256
extern double *a, *x, *y, *z;
void work()
{
        int i;

        for (i = 0; i < DATA_ENTRIES; ++i)
               z[i] = a[i] * x[i] + y[i];
}

[hjl@gnu-skx-1 tmp]$ gcc -S -O3 y.c -mavx2 -mfma
[hjl@gnu-skx-1 tmp]$ cat y.s
        .file   "y.c"
        .text
        .p2align 4
        .globl  work
        .type   work, @function
work:
.LFB0:
        .cfi_startproc
        movq    z(%rip), %rdx
        movq    x(%rip), %rsi
        movq    a(%rip), %rcx
        movq    y(%rip), %rdi
        leaq    8(%rsi), %r8
        movq    %rdx, %rax
        subq    %r8, %rax
        leaq    8(%rcx), %r9
        cmpq    $16, %rax
        movq    %rdx, %rax
        seta    %r8b
        subq    %r9, %rax
        cmpq    $16, %rax
        seta    %al
        testb   %al, %r8b
        je      .L5
        leaq    8(%rdi), %r8
        movq    %rdx, %rax
        subq    %r8, %rax
        cmpq    $16, %rax
        jbe     .L5
        xorl    %eax, %eax
        .p2align 4,,10
        .p2align 3
.L3:
        vmovupd (%rcx,%rax), %xmm3
        vmovupd (%rsi,%rax), %xmm4
        vinsertf128     $0x1, 16(%rcx,%rax), %ymm3, %ymm0
        vinsertf128     $0x1, 16(%rsi,%rax), %ymm4, %ymm2
        vmovupd (%rdi,%rax), %xmm5
        vinsertf128     $0x1, 16(%rdi,%rax), %ymm5, %ymm1
        vfmadd132pd     %ymm2, %ymm1, %ymm0
        vmovupd %xmm0, (%rdx,%rax)
        vextractf128    $0x1, %ymm0, 16(%rdx,%rax)
        addq    $32, %rax
        cmpq    $2048, %rax
        jne     .L3
        vzeroupper
        ret
.L5:
        xorl    %eax, %eax
        .p2align 4,,10
        .p2align 3
.L2:
        vmovsd  (%rcx,%rax), %xmm0
        vmovsd  (%rdi,%rax), %xmm6
        vfmadd132sd     (%rsi,%rax), %xmm6, %xmm0
        vmovsd  %xmm0, (%rdx,%rax)
        addq    $8, %rax
        cmpq    $2048, %rax
        jne     .L2
        ret
        .cfi_endproc
.LFE0:
        .size   work, .-work
        .ident  "GCC: (GNU) 10.2.1 20210119 (Red Hat 10.2.1-10)"
        .section        .note.GNU-stack,"",@progbits
[hjl@gnu-skx-1 tmp]$ gcc -S -O3 y.c -mavx2 -mfma -mtune=haswell
[hjl@gnu-skx-1 tmp]$ cat y.s
        .file   "y.c"
        .text
        .p2align 4
        .globl  work
        .type   work, @function
work:
.LFB0:
        .cfi_startproc
        movq    z(%rip), %rdx
        movq    x(%rip), %rsi
        movq    a(%rip), %rcx
        movq    y(%rip), %rdi
        leaq    8(%rsi), %r8
        movq    %rdx, %rax
        subq    %r8, %rax
        leaq    8(%rcx), %r9
        cmpq    $16, %rax
        movq    %rdx, %rax
        seta    %r8b
        subq    %r9, %rax
        cmpq    $16, %rax
        seta    %al
        testb   %al, %r8b
        je      .L5
        leaq    8(%rdi), %r8
        movq    %rdx, %rax
        subq    %r8, %rax
        cmpq    $16, %rax
        jbe     .L5
        xorl    %eax, %eax
        .p2align 4,,10
        .p2align 3
.L3:
        vmovupd (%rcx,%rax), %ymm0
        vmovupd (%rdi,%rax), %ymm1
        vfmadd132pd     (%rsi,%rax), %ymm1, %ymm0
        vmovupd %ymm0, (%rdx,%rax)
        addq    $32, %rax
        cmpq    $2048, %rax
        jne     .L3
        vzeroupper
        ret
.L5:
        xorl    %eax, %eax
        .p2align 4,,10
        .p2align 3
.L2:
        vmovsd  (%rcx,%rax), %xmm0
        vmovsd  (%rdi,%rax), %xmm2
        vfmadd132sd     (%rsi,%rax), %xmm2, %xmm0
        vmovsd  %xmm0, (%rdx,%rax)
        addq    $8, %rax
        cmpq    $2048, %rax
        jne     .L2
        ret
        .cfi_endproc
.LFE0:
        .size   work, .-work
        .ident  "GCC: (GNU) 10.2.1 20210119 (Red Hat 10.2.1-10)"
        .section        .note.GNU-stack,"",@progbits
[hjl@gnu-skx-1 tmp]$

[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172

--- Comment #9 from Hongtao.liu <crazylht at gmail dot com> ---
> .L3:
> 	vmovupd	(%rcx,%rax), %xmm3
> 	vmovupd	(%rsi,%rax), %xmm4
> 	vinsertf128	$0x1, 16(%rcx,%rax), %ymm3, %ymm0
> 	vinsertf128	$0x1, 16(%rsi,%rax), %ymm4, %ymm2
> 	vmovupd	(%rdi,%rax), %xmm5
> 	vinsertf128	$0x1, 16(%rdi,%rax), %ymm5, %ymm1
> 	vfmadd132pd	%ymm2, %ymm1, %ymm0
> 	vmovupd	%xmm0, (%rdx,%rax)
> 	vextractf128	$0x1, %ymm0, 16(%rdx,%rax)
> 	addq	$32, %rax
> 	cmpq	$2048, %rax
> 	jne	.L3
> 	vzeroupper
> 	ret

The kernel loop could be better as

.L3:
        vmovupd (%rcx,%rax), %ymm0
        vmovupd (%rdi,%rax), %ymm1
        vfmadd132pd     (%rsi,%rax), %ymm1, %ymm0
        vmovupd %ymm0, (%rdx,%rax)
        addq    $32, %rax
        cmpq    $2048, %rax
        jne     .L3

[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172

--- Comment #10 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Hongtao.liu from comment #9)
> > .L3:
> > 	vmovupd	(%rcx,%rax), %xmm3
> > 	vmovupd	(%rsi,%rax), %xmm4
> > 	vinsertf128	$0x1, 16(%rcx,%rax), %ymm3, %ymm0
> > 	vinsertf128	$0x1, 16(%rsi,%rax), %ymm4, %ymm2
> > 	vmovupd	(%rdi,%rax), %xmm5
> > 	vinsertf128	$0x1, 16(%rdi,%rax), %ymm5, %ymm1
> > 	vfmadd132pd	%ymm2, %ymm1, %ymm0
> > 	vmovupd	%xmm0, (%rdx,%rax)
> > 	vextractf128	$0x1, %ymm0, 16(%rdx,%rax)
> > 	addq	$32, %rax
> > 	cmpq	$2048, %rax
> > 	jne	.L3
> > 	vzeroupper
> > 	ret
> 
> The kernel loop could be better as
>  
> .L3:
> 	vmovupd	(%rcx,%rax), %ymm0
> 	vmovupd	(%rdi,%rax), %ymm1
> 	vfmadd132pd	(%rsi,%rax), %ymm1, %ymm0
> 	vmovupd	%ymm0, (%rdx,%rax)
> 	addq	$32, %rax
> 	cmpq	$2048, %rax
> 	jne	.L3

It went into movmisalign<mode>, and finally be splitted into parts by
ix86_avx256_split_vector_move_misalign, and the differences between
-mtune=generic and -mtune=haswell matters here is
X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL and
X86_TUNE_AVX256_UNALIGNED_STORE_OPTIMAL

-------
/* X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL: if false, unaligned loads are
   split.  */
DEF_TUNE (X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL, "256_unaligned_load_optimal",
          ~(m_NEHALEM | m_SANDYBRIDGE | m_GENERIC))

/* X86_TUNE_AVX256_UNALIGNED_STORE_OPTIMAL: if false, unaligned stores are
   split.  */
DEF_TUNE (X86_TUNE_AVX256_UNALIGNED_STORE_OPTIMAL,
"256_unaligned_store_optimal",
          ~(m_NEHALEM | m_SANDYBRIDGE | m_BDVER | m_ZNVER1 | m_GENERIC))
--------

manually adding two tunes to generic
gcc -S -O3 y.c -mavx2 -mfma
-mtune-ctrl="256_unaligned_load_optimal,256_unaligned_store_optimal"
successfully generate optimial codes.

.L3:
        vmovupd (%rcx,%rax), %ymm0
        vmovupd (%rdi,%rax), %ymm1
        vfmadd132pd     (%rsi,%rax), %ymm1, %ymm0
        vmovupd %ymm0, (%rdx,%rax)
        addq    $32, %rax
        cmpq    $2048, %rax
        jne     .L3
        vzeroupper
        ret
.L5:

[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by hongtao Liu <liuhongt@gcc.gnu.org>:

https://gcc.gnu.org/g:b80fefd626460fb8924248622ba59dd56246703e

commit r11-7115-gb80fefd626460fb8924248622ba59dd56246703e
Author: liuhongt <hongtao.liu@intel.com>
Date:   Thu Jan 28 14:07:00 2021 +0800

    Enable X86_TUNE_AVX256_UNALIGNED_{LOADï¼STORE}_OPTIMAL in generic tune.

    gcc/ChangeLog:

            PR target/98172
            * config/i386/x86-tune.def
(X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL):
            Remove m_GENERIC from ~list.
            (X86_TUNE_AVX256_UNALIGNED_STORE_OPTIMAL): Ditto.

[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.0                        |11.2

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.1 has been released, retargeting bugs to GCC 11.2.

[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.2                        |11.3

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.2 is being released, retargeting bugs to GCC 11.3

[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.3                        |11.4

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.3 is being released, retargeting bugs to GCC 11.4.

[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.4                        |11.5

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.4 is being released, retargeting bugs to GCC 11.5.