[llvm-commits] PATCH: remove VICmp and VFCmp.

[Dan Gohman]

On Jul 8, 2009, at 2:09 PM, David Greene wrote:


> On Tuesday 07 July 2009 15:16, Chris Lattner wrote:
>
>
>>> Work has been one to support vector [fi]cmp in the IR, however no
>>>
>>> work has been done to support it in CodeGen yet. Adding support in
>>>
>>> CodeGen will require a variety of fairly straight-forward
>>>
>>> changes, plus finding a solution for vectors of i1 in CodeGen.
>>>
>>
>>
>> I don't see a need to fix the "vector of i1" issue right now.  In
>>
>> fact, I don't see an issue at all.
>>
>>
>>
>> There are two things we care about: making compare+sext turn into the
>>
>> current nice code that v*cmp produces, and eventually handling  
>> compare
>>
>> +select.  Both of these idioms are trivial enough that they could be
>>
>> handled by pre-legalize dag combine, forming (e.g.) ISD::VSETCC
>>
>> nodes.  Then legalize won't ever see vectors of i1 in code that we
>>
>> care about.
>>
>
> I haven't been tracking this, so can someone explain what the  
> "vectors of
> i1 problem" is?  Is it a problem of how to generate code on  
> architectures
> that don't have a mask concept?

Yes. One approach to the problem to require IR producers to know that
certain targets require comparison results to be sign-extended into
vectors of larger integer types. This is essentially the solution
being used today. Another is to enhance CodeGen to have better support
for vectors of i1 on architectures where they aren't "legal".

>
> compare+select is not enough for architectures like Larrabee.  We  
> are very
> soon going to want to support full vector predication, so it would  
> seem like
> solving the vectors of i1 problem is moderately important.

Compare+select with plain vectors of i1 is one step of many. The LLVM IR
now has the needed support for compare+select, so this step will be
basically contained within CodeGen. And, it'll help guide future steps.

Dan