This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [vec-cmp, patch 1/6] Add optabs for vector comparison
- From: Ilya Enkovich <enkovich dot gnu at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 5 Nov 2015 19:01:54 +0300
- Subject: Re: [vec-cmp, patch 1/6] Add optabs for vector comparison
- Authentication-results: sourceware.org; auth=none
- References: <20151008145221 dot GB63757 at msticlxl57 dot ims dot intel dot com> <5627CA8B dot 8040106 at redhat dot com> <CAMbmDYZCEh6kXcYYzaXtKrKm25+VQEp9zfAa3aKOSE-P2L9k2g at mail dot gmail dot com> <56290634 dot 5020706 at redhat dot com> <CAMbmDYbeTMSXDgjeCx0mUhdgh=w4354L_xrt2t73=ntF-y8CvA at mail dot gmail dot com> <562FE402 dot 8020801 at redhat dot com>
2015-10-27 23:52 GMT+03:00 Jeff Law <law@redhat.com>:
>
> 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