From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id BC336388C031 for ; Wed, 10 Jun 2020 09:22:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BC336388C031 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=richard.sandiford@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6E90D1F1; Wed, 10 Jun 2020 02:22:52 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 64BA73F73D; Wed, 10 Jun 2020 02:22:51 -0700 (PDT) From: Richard Sandiford To: "Kewen.Lin" Mail-Followup-To: "Kewen.Lin" , GCC Patches , Bill Schmidt , Richard Guenther , Segher Boessenkool , dje.gcc@gmail.com, richard.sandiford@arm.com Cc: GCC Patches , Bill Schmidt , Richard Guenther , Segher Boessenkool , dje.gcc@gmail.com Subject: Re: [PATCH 1/7 V2] ifn/optabs: Support vector load/store with length References: <30906c0d-3b9f-e1e6-156f-c01fcf229cb9@linux.ibm.com> <93f9e4cf-351d-5f89-65b5-7dbc97ce13b9@linux.ibm.com> <8f64b58b-050c-2e1c-36c6-049a07eceee7@linux.ibm.com> Date: Wed, 10 Jun 2020 10:22:48 +0100 In-Reply-To: <8f64b58b-050c-2e1c-36c6-049a07eceee7@linux.ibm.com> (Kewen Lin's message of "Wed, 10 Jun 2020 14:41:48 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Wed, 10 Jun 2020 09:22:54 -0000 "Kewen.Lin" writes: > @@ -2497,6 +2499,9 @@ expand_mask_load_optab_fn (internal_fn, gcall *stmt= , convert_optab optab) >=20=20 > if (optab =3D=3D vec_mask_load_lanes_optab) > icode =3D get_multi_vector_move (type, optab); > + else if (optab =3D=3D lenload_optab) > + icode =3D convert_optab_handler (optab, TYPE_MODE (type), > + targetm.vectorize.length_mode); > else > icode =3D convert_optab_handler (optab, TYPE_MODE (type), > TYPE_MODE (TREE_TYPE (maskt))); I think lenload_optab should just be a direct optab, based only on the vector mode. It seems unlikely that targets would provide the =E2=80=9Csame=E2=80=9D load with different length modes. > @@ -2507,15 +2512,20 @@ expand_mask_load_optab_fn (internal_fn, gcall *st= mt, convert_optab optab) > target =3D expand_expr (lhs, NULL_RTX, VOIDmode, EXPAND_WRITE); > create_output_operand (&ops[0], target, TYPE_MODE (type)); > create_fixed_operand (&ops[1], mem); > - create_input_operand (&ops[2], mask, TYPE_MODE (TREE_TYPE (maskt))); > + if (optab =3D=3D lenload_optab) > + create_convert_operand_from (&ops[2], mask, targetm.vectorize.length= _mode, > + TYPE_UNSIGNED (TREE_TYPE (maskt))); The mode argument should be TYPE_MODE (TREE_TYPE (maskt)) -- i.e. the arguments should specify the precision and signedness of the existing rtx. Hopefully this means that we don't need the target hook at all. Thanks, Richard