On 11/05/2015 09:01 AM, Ilya Enkovich wrote:
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?
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
