From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19681 invoked by alias); 9 Sep 2019 13:39:38 -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 19673 invoked by uid 89); 9 Sep 2019 13:39:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=coming, H*i:sk:c10b5c4, H*f:sk:c10b5c4 X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Sep 2019 13:39:37 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 363D2ACC9; Mon, 9 Sep 2019 13:39:35 +0000 (UTC) Date: Mon, 09 Sep 2019 13:39:00 -0000 From: Richard Biener To: =?ISO-8859-15?Q?Martin_Li=A8ka?= cc: gcc-patches@gcc.gnu.org, Marc Glisse , Li Jia He , Andrew Pinski , Jeff Law , Segher Boessenkool , wschmidt@linux.ibm.com, Martin Liska Subject: Re: [PATCH 1/2] Auto-generate maybe_fold_and/or_comparisons from match.pd In-Reply-To: Message-ID: References: <1561615913-22109-1-git-send-email-helijia@linux.ibm.com> <6fb28248-5134-cec5-5045-45253e4d2eb0@redhat.com> <6d333ccf-9905-e929-c2dc-fc611ff929f1@linux.ibm.com> <845bc280-7bd6-509b-3830-4ebde50f1b20@linux.ibm.com> <863e9c71-7639-eaf9-fa13-32515ce0452f@suse.cz> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1609908220-1052435559-1568036375=:5566" X-SW-Source: 2019-09/txt/msg00513.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609908220-1052435559-1568036375=:5566 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-length: 1531 On Mon, 9 Sep 2019, Martin Liška wrote: > On 9/9/19 3:10 PM, Marc Glisse wrote: > > On Mon, 9 Sep 2019, Martin Liška wrote: > > > >> I'm sending slightly updated version of the patch where we > >> need to properly select type in maybe_fold_comparisons_from_match_pd > >> function for the created SSA_NAMEs. We can be called for a VECTOR_TYPE > >> and so that we can't return a boolean_type_node. > > > > +  tree type = TREE_TYPE (op1a); > > +  if (TREE_CODE (type) != VECTOR_TYPE) > > +    type = boolean_type_node; > > > > Don't you need build_same_sized_truth_vector_type or something, for instance with AVX512? > > > > Also, IIRC EQ_EXPR for vectors can return either a vector or a boolean. I don't know if we can end up here with both versions, but if we can, guessing the type could be dangerous. Would it be hard to add a type argument to those functions and delegate this to the caller? Any better idea (maybe this is already safe and I am just missing it)? > > Richi can you help us here? I'm not sure what guarantees do we have here in GIMPLE? Oops, I missed this hunk - the caller needs to pass this down, but at least from the ifcombine use we are always coming from a if (a CMP b) context and thus a boolean_type_node result type. For the reassoc case there's indeed nothing preventing from vector typed comparisons sneaking in here, likewise recursion via or_var_with_comparison_1 might run into vectors. Thus the toplevel interface has to pass down the (common) type of the two comparisons. Richard. ---1609908220-1052435559-1568036375=:5566--