2015-10-27 23:52 GMT+03:00 Jeff Law <l...@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