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 11E0C3851C29; Mon, 18 May 2020 10:01:15 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 11E0C3851C29
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1589796075;
 bh=zERYWYjtEOqj0EDUxjnYXv7QhOBnSl2BriWcYzEFIL0=;
 h=From:To:Subject:Date:In-Reply-To:References:From;
 b=FzkW6obDldi7jCePJg1IYMhHkahe+oOjKMsmsVZBXdaUKH5UI+yrn5fojM2MgMXcG
 4WUhzWP1SnZMd07poKi+yIc8SN4fi5+B37PAjxzM0c1MHPDyzpfpcQyCtqj0TherSG
 nefHyQ1ZxX0mGsINuSaRSpqbut0dmBox2DpZ06fI=
From: "crazylht at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/94962] Suboptimal AVX2 code for
 _mm256_zextsi128_si256(_mm_set1_epi8(-1))
Date: Mon, 18 May 2020 10:01:14 +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: 10.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: crazylht at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-94962-4-OHyxcG87qA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-94962-4@http.gcc.gnu.org/bugzilla/>
References: <bug-94962-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: <http://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: <http://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 18 May 2020 10:01:15 -0000

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

--- Comment #4 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Jakub Jelinek from comment #2)
> But such an instruction isn't always redundant, it really depends on what
> the previous setter of the register did, whether the upper 128 bit of the
> 256-bit register are already guaranteed to be zero or not.
----
(define_insn "avx_vec_concat<mode>"
  [(set (match_operand:V_256_512 0 "register_operand" "=3Dx,v,x,Yv")
        (vec_concat:V_256_512
          (match_operand:<ssehalfvecmode> 1 "nonimmediate_operand" "x,v,xm,=
vm")
          (match_operand:<ssehalfvecmode> 2 "nonimm_or_0_operand"
"xm,vm,C,C")))]

define_insn "*<extract_type>_vinsert<shuffletype><extract_suf>_0"
  [(set (match_operand:AVX512_VEC 0 "register_operand" "=3Dv,x,Yv")
        (vec_merge:AVX512_VEC
          (match_operand:AVX512_VEC 1 "reg_or_0_operand" "v,C,C")
          (vec_duplicate:AVX512_VEC
                (match_operand:<ssequartermode> 2 "nonimmediate_operand"
"vm,xm,vm"))
          (match_operand:SI 3 "const_int_operand" "n,n,n")))]

----
Upper part already zeroed.

> Thus the #c1 patch looks incorrect to me, one would need peephole2s or so=
me
> combine patterns or target specific pass etc. to discover that at least f=
or
> the common cases; and it isn't something we model in the RTL patterns (wh=
at
> insns guarantee which upper bits zero and what do not; and for some there
> can be different choices even in the same define_insn, we could implement
> something using widened registers and then there would be no guarantee et=
c.).=