From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63558 invoked by alias); 30 Sep 2018 08:55:57 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 37051 invoked by uid 89); 30 Sep 2018 08:53:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=risks X-HELO: mail2-relais-roc.national.inria.fr Received: from mail2-relais-roc.national.inria.fr (HELO mail2-relais-roc.national.inria.fr) (192.134.164.83) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 30 Sep 2018 08:53:45 +0000 Received: from ip-133.net-89-2-166.rev.numericable.fr (HELO stedding) ([89.2.166.133]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Sep 2018 10:53:42 +0200 Date: Sun, 30 Sep 2018 10:55:00 -0000 From: Marc Glisse Reply-To: gcc-patches@gcc.gnu.org To: "H.J. Lu" cc: gcc-patches@gcc.gnu.org, Uros Bizjak Subject: Re: [PATCH] x86: Add pmovzx/pmovsx patterns with SI/DI operands In-Reply-To: <20180929220425.4714-1-hjl.tools@gmail.com> Message-ID: References: <20180929220425.4714-1-hjl.tools@gmail.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-SW-Source: 2018-09/txt/msg01785.txt.bz2 On Sat, 29 Sep 2018, H.J. Lu wrote: > Add pmovzx/pmovsx patterns with SI and DI operands for pmovzx/pmovsx > instructions which only read the low 4 or 8 bytes from the source. Hello, I am wondering a few things (these are questions, I am not asking for changes): Should we change the builtin and make it take a shorter argument, so it is visible to gimple optimizers that the high part is unused? But then would that shorter type be v8qi (we don't really have that type) or di (risks trying to use general regs?)? > +(define_insn "*sse4_1_v8qiv8hi2" > + [(set (match_operand:V8HI 0 "register_operand" "=Yr,*x,v") > + (any_extend:V8HI > + (vec_select:V8QI > + (subreg:V16QI > + (vec_concat:V2DI > + (match_operand:DI 1 "nonimmediate_operand" "Yrm,*xm,vm") > + (const_int 0)) 0) > + (parallel [(const_int 0) (const_int 1) > + (const_int 2) (const_int 3) > + (const_int 4) (const_int 5) > + (const_int 6) (const_int 7)]))))] There is code in simplify-rtx.c that handles (vec_select (vec_concat x y) z) when vec_select only picks from x. We could extend it to handle an intermediate subreg/cast, which would yield something like: (any_extend:V8HI (subreg:V8QI (match_operand:DI))) or maybe even (any_extend:V8HI (match_operand:V8QI)) Would this be likely to work? Is it desirable? -- Marc Glisse