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

[Dan Gohman]

On Jul 6, 2009, at 10:10 AM, Chris Lattner wrote:


>
> On Jul 5, 2009, at 10:16 PM, Nick Lewycky wrote:
>
>
>> This patch removes vicmp and vfcmp, which has the positive side that
>>
>> it fixes existing type-safety bugs and simplifies some code, but a
>>
>> downside in that it XFAILs 9 CodeGen tests.
>>
>
> I haven't had a chance to look at the patch, but removing v[fi]cmp
> will almost certainly break clang (which generates them for vector
> comparisons in opencl/ext_vector mode).  The right way to remove this
> is to make codegen pattern match [fi]cmp+sext to the same nodes it is
> using for v[fi]cmp, then change clang to generate [fi]cmp+sext instead
> of v[if]cmp, then nuke v[fi]cmp.  This way we won't loose any codegen
> capability and clang will still build :).

Vector [fi]cmp are not yet ready to replace v[fi]cmp, and there's
more work required than just adding patterns.

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.

Here's a simple example:

define <4 x float> @foo(<4 x float> %a, <4 x float> %b,
                         <4 x float> %c, <4 x float> %d) {
   %y = fcmp olt <4 x float> %a, %b
   %z = select <4 x i1> %y, <4 x float> %c, <4 x float> %d
   ret <4 x float> %z
}

%y has type <4 x i1>. This is not a legal type on most current
architectures. But, many architectures have ways of supporting
this kind of code, often by putting the comparison result in a
<4 x i32> register.

The main twist is that a type like <4 x i1> might be legalized
to either <4 x i32> or <4 x i64> on a target like x86, depending
on the type of the comparison operands, so the current
getTypeToTransformTo, which assumes that every type has a
unique destination type, isn't sufficient. But this just needs
some creativity.

Dan