From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34773 invoked by alias); 6 Nov 2015 16:15:31 -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 34756 invoked by uid 89); 6 Nov 2015 16:15:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 06 Nov 2015 16:15:28 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id DBCA2C0003F6; Fri, 6 Nov 2015 16:15:26 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-107.phx2.redhat.com [10.3.113.107]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tA6GFQlZ029131; Fri, 6 Nov 2015 11:15:26 -0500 Subject: Re: [vec-cmp, patch 1/6] Add optabs for vector comparison To: Ilya Enkovich References: <20151008145221.GB63757@msticlxl57.ims.intel.com> <5627CA8B.8040106@redhat.com> <56290634.5020706@redhat.com> <562FE402.8020801@redhat.com> Cc: gcc-patches From: Jeff Law Message-ID: <563CD21E.6010800@redhat.com> Date: Fri, 06 Nov 2015 16:15:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00671.txt.bz2 On 11/05/2015 09:01 AM, Ilya Enkovich wrote: > 2015-10-27 23:52 GMT+03:00 Jeff Law : >> >> Sigh. I searched for the enum type, not for CODE_FOR_nothing ;( My bad. >> >> If it's easy to get rid of, yes. I believe we've got 3 uses of >> CODE_FOR_nothing. AFAICT in none of those cases do we care about the code >> other than does it correspond to CODE_FOR_nothing. >> >> Ideally we'd like to have both optabs-query and optabs-tree not know about >> insn codes. The former is supposed to be IR agnostic, but insn codes are >> part of the RTL IR, so that's a wart. The latter is supposed to be tree >> specific and thus shouldn't know about the RTL IR either. >> >> I'd settle for getting the wart out of optabs-tree and we can put further >> cleanup of optabs-query in the queue. >> >> To get the wart out of optabs-tree all I think we need is a true boolean >> function that tells us if there's a suitable optab. >> >> It's unfortunate that the routines exported by optabs-query are >> can_{extend,float,fix}_p since those would fairly natural for the boolean >> query we want to make and they're used elsewhere, but not in a boolean form. >> >> I think that we ought to rename the existing uses & definition of can_XXX_p >> that are exported by optabs-query.c, then creating new can_XXX_p for those >> uses that just care about the boolean status should work. At that point we >> remove insn-codes.h from optab-tree.c. > > Do you want this refactoring be a part of this patch or series? I would have preferred before, but I think we're at a state where doing it after makes more sense. So let's unblock this patch and I'll make an exception for the minor refactoring to go in shortly after stage1 closes. Jeff