From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id D6BBD3857034; Thu, 21 Jan 2021 01:55:23 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D6BBD3857034
From: "crazylht at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/98172] Update -mtune=generic for the current Intel and
 AMD processors
Date: Thu, 21 Jan 2021 01:55:23 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 11.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: crazylht at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-98172-4-feJGUcZijl@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-98172-4@http.gcc.gnu.org/bugzilla/>
References: <bug-98172-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jan 2021 01:55:24 -0000

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

--- 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
>=20
> The kernel loop could be better as
>=20=20
> .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=3Dgeneric and -mtune=3Dhaswell 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_optim=
al",
          ~(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=3D"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:=