[vec-cmp, patch 1/6] Add optabs for vector comparison

[Jeff Law]

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