From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5848 invoked by alias); 6 Sep 2019 12:58:51 -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 5839 invoked by uid 89); 6 Sep 2019 12:58:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-16.6 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3 autolearn=ham version=3.3.1 spammy=UD:optabs.c, optabs.c, sk:can_vec, optabsc X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Sep 2019 12:58:50 +0000 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 930491570; Fri, 6 Sep 2019 05:58:48 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.99.62]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 83E623F718; Fri, 6 Sep 2019 05:58:47 -0700 (PDT) From: Richard Sandiford To: Ilya Leoshkevich Mail-Followup-To: Ilya Leoshkevich ,gcc-patches@gcc.gnu.org, richard.guenther@gmail.com, segher@kernel.crashing.org, joseph@codesourcery.com, krebbel@linux.ibm.com, rdapp@linux.ibm.com, richard.sandiford@arm.com Cc: gcc-patches@gcc.gnu.org, richard.guenther@gmail.com, segher@kernel.crashing.org, joseph@codesourcery.com, krebbel@linux.ibm.com, rdapp@linux.ibm.com Subject: Re: [PATCH v3 3/9] Introduce can_vector_compare_p function References: <20190905111019.8951-1-iii@linux.ibm.com> <20190905111019.8951-4-iii@linux.ibm.com> Date: Fri, 06 Sep 2019 12:58:00 -0000 In-Reply-To: <20190905111019.8951-4-iii@linux.ibm.com> (Ilya Leoshkevich's message of "Thu, 5 Sep 2019 13:10:13 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00382.txt.bz2 Ilya Leoshkevich writes: > @@ -329,6 +332,34 @@ expand_vec_cmp_expr_p (tree value_type, tree mask_type, enum tree_code code) > return false; > } > > +/* Return TRUE iff vcond_optab/vcondu_optab support the given tree > + comparison. */ Nit: better to use "true" rather than "TRUE" in modern comments; TRUE is a hold-over from C90 days. > + > +static bool > +vcond_icode_p (tree value_type, tree cmp_op_type, enum tree_code code) > +{ > + enum rtx_code rcode = get_rtx_code_safe (code, TYPE_UNSIGNED (cmp_op_type)); > + if (rcode == LAST_AND_UNUSED_RTX_CODE) > + /* This may happen, for example, if code == SSA_NAME, in which case we > + cannot be certain whether a vector insn is available. */ > + return false; IMO expand_vec_cond_expr_p should exit early for SSA names before calling this function (but after checking get_vcond_mask_icode). Asserting for a comparison seems reasonable here. > diff --git a/gcc/optabs.c b/gcc/optabs.c > index cdd07f3e53f..479789570a9 100644 > --- a/gcc/optabs.c > +++ b/gcc/optabs.c > @@ -3819,6 +3819,30 @@ can_compare_p (enum rtx_code code, machine_mode mode, > return 0; > } > > +/* Return whether back-end can emit a vector comparison insn(s) using a give> + CODE, with operands with CMP_OP_MODE, producing a result with VALUE_MODE, > + in order to achieve a PURPOSE. */ Maybe: /* Return whether the backend can emit a vector comparison for code CODE, comparing operands of mode CMP_OP_MODE and producing a result with VALUE_MODE. */ > + > +bool > +can_vector_compare_p (enum rtx_code code, machine_mode value_mode, > + machine_mode cmp_op_mode, > + enum can_vector_compare_purpose purpose) I think we should leave out the purpose argument until it's needed. (Sorry if someone else said the opposite, can't remember now.) Maybe can_vcond_compare_p would be more consistent with the other function names in the patch. Thanks, Richard