From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) by sourceware.org (Postfix) with ESMTPS id E9F1E386CE4B for ; Thu, 30 Jun 2022 08:45:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E9F1E386CE4B Received: by mail-qv1-xf30.google.com with SMTP id u14so26028943qvv.2 for ; Thu, 30 Jun 2022 01:45:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DZFNPblN+28ZPKjLd2H81fz3KDQ++IgyjSb5Wfe/r2E=; b=yqg2PYPgSH3ffMAv4YMm4uGFJDqkjIb5pXHHM85yphXfpKcogempEqYYvx6sNAett8 4nc6ifJT8RuybxNL+LYDK4Fv7aZ1nNRuMv6L99FUaSahsNybhvBYk85SZyoaxXuEKTaC yScUB10XtRi9iq8xZqal7wicxn+0AkP8G8DKeXjPOYT/yTfh7Wzqhh3TvF5vb64ToLY/ TXvyATtIRG7wjn81/bdeREDv+aww5b7HnKwS9tcenU9dIv/sdy+E0/w4BQhIflfqZury Q+qflA8xda1fAkmokgD5hRv7UhT9TzY88+mebZyEn+HX28w7umG82o+ZR5MMsd/ywurW rakA== X-Gm-Message-State: AJIora+U2pd2JxTnqsOGzIGuj6iDOKxlRN52LFhtVc6UlN/JXoGZO7iM TlqwGKrnjgCIJarBWYaRoEz+WaIzJF2LK1EIYQH9kfaWWZvgqg== X-Google-Smtp-Source: AGRyM1vFFZdKjD+Li4Qwmw0OzzBMMYTB2VsFHc/N+k9b+6Kwf87XpPB3tjUW9AI8rZWMRz5i1GWVLViX35eXjvIo680= X-Received: by 2002:a05:6214:248b:b0:470:4ef5:7159 with SMTP id gi11-20020a056214248b00b004704ef57159mr10228995qvb.48.1656578715263; Thu, 30 Jun 2022 01:45:15 -0700 (PDT) MIME-Version: 1.0 References: <20220630055907.50030-1-haochen.jiang@intel.com> In-Reply-To: From: Uros Bizjak Date: Thu, 30 Jun 2022 10:45:04 +0200 Message-ID: Subject: Re: [PATCH] i386: Extend cvtps2pd to memory To: "Jiang, Haochen" Cc: "gcc-patches@gcc.gnu.org" , "Liu, Hongtao" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2022 08:45:17 -0000 On Thu, Jun 30, 2022 at 9:41 AM Uros Bizjak wrote: > > On Thu, Jun 30, 2022 at 9:24 AM Jiang, Haochen wrote: > > > > > -----Original Message----- > > > From: Uros Bizjak > > > Sent: Thursday, June 30, 2022 2:20 PM > > > To: Jiang, Haochen > > > Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao > > > Subject: Re: [PATCH] i386: Extend cvtps2pd to memory > > > > > > On Thu, Jun 30, 2022 at 7:59 AM Haochen Jiang > > > wrote: > > > > > > > > Hi all, > > > > > > > > This patch aims to fix the cvtps2pd insn, which should also work on > > > > memory operand but currently does not. After this fix, when loop == 2, > > > > it will eliminate movq instruction. > > > > > > > > Regtested on x86_64-pc-linux-gnu. Ok for trunk? > > > > > > > > BRs, > > > > Haochen > > > > > > > > gcc/ChangeLog: > > > > > > > > PR target/43618 > > > > * config/i386/sse.md (extendv2sfv2df2): New define_expand. > > > > (sse2_cvtps2pd_load): Rename extendvsdfv2df2. Rename FROM ... Please also mention change to sse2_cvtps2pd. > > > > > > > > gcc/testsuite/ChangeLog: > > > > > > > > PR target/43618 > > > > * gcc.target/i386/pr43618-1.c: New test. > > > > > > This patch could be as simple as: > > > > > > diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md index > > > 8cd0f617bf3..c331445cb2d 100644 > > > --- a/gcc/config/i386/sse.md > > > +++ b/gcc/config/i386/sse.md > > > @@ -9195,7 +9195,7 @@ > > > (define_insn "extendv2sfv2df2" > > > [(set (match_operand:V2DF 0 "register_operand" "=v") > > > (float_extend:V2DF > > > - (match_operand:V2SF 1 "register_operand" "v")))] > > > + (match_operand:V2SF 1 "nonimmediate_operand" "vm")))] > > > "TARGET_MMX_WITH_SSE" > > > "%vcvtps2pd\t{%1, %0|%0, %1}" > > > [(set_attr "type" "ssecvt") > > > > We also tested on this version, it is ok. > > > > The reason why the patch looks like this is because in the previous insn > > sse2_cvtps2pd, the constraint vm and vector_operand > > actually does not match the actual instruction. Memory operand is V2SF, > > not V4SF. > > > > Therefore, we changed the constraint in that insn. Then it caused another issue. > > For memory operand, it seems that we cannot generate those mask instructions. > > So I change the pattern to how extendv2hfv2df2 works. > > If you want to change the memory access in sse2_cvtps2pd, > then please see how e.g. v2hiv2di is handled in sse.md. In > addition to two instructions, you will need one define_insn_and_split > with a pre-reload splitter. Oh, nowadays combine does vec_select from a paradoxical subreg on its own. +(define_expand "extendv2sfv2df2" + [(set (match_operand:V2DF 0 "register_operand") + (float_extend:V2DF + (match_operand:V2SF 1 "nonimmediate_operand")))] + "TARGET_MMX_WITH_SSE" +{ + if (!MEM_P (operands[1])) + { You will need force reg here: rtx op1 = force_reg (V2SFmode, operands[1]); + operands[1] = lowpart_subreg (V4SFmode, op1, V2SFmode); + emit_insn (gen_sse2_cvtps2pd (operands[0], operands[1])); + DONE; + } +}) -(define_insn "extendv2sfv2df2" +(define_insn "sse2_cvtps2pd_load" Please name this insn "*sse2_cvtps2pd_1". Please note the star at the beginning, You don't have to make the name public. OK with the above changes. Thanks, Uros,