From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105708 invoked by alias); 5 Nov 2015 16:02:07 -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 105698 invoked by uid 89); 5 Nov 2015 16:02:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-io0-f178.google.com Received: from mail-io0-f178.google.com (HELO mail-io0-f178.google.com) (209.85.223.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 05 Nov 2015 16:01:56 +0000 Received: by iody8 with SMTP id y8so94077810iod.1 for ; Thu, 05 Nov 2015 08:01:54 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.18.78 with SMTP id a75mr4476426ioj.91.1446739314502; Thu, 05 Nov 2015 08:01:54 -0800 (PST) Received: by 10.36.209.7 with HTTP; Thu, 5 Nov 2015 08:01:54 -0800 (PST) In-Reply-To: <562FE402.8020801@redhat.com> References: <20151008145221.GB63757@msticlxl57.ims.intel.com> <5627CA8B.8040106@redhat.com> <56290634.5020706@redhat.com> <562FE402.8020801@redhat.com> Date: Thu, 05 Nov 2015 16:02:00 -0000 Message-ID: Subject: Re: [vec-cmp, patch 1/6] Add optabs for vector comparison From: Ilya Enkovich To: Jeff Law Cc: gcc-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00485.txt.bz2 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? Thanks, Ilya > > Jeff