[LLVMdev] killing vicmp and vfcmp

[Nick Lewycky]

Nate Begeman wrote:
> On Jun 24, 2009, at 10:02 AM, Chris Lattner wrote:
> 
>> On Jun 24, 2009, at 12:47 AM, Duncan Sands wrote:
>>
>>> Hi Nick,
>>>
>>>> Now that icmp and fcmp have supported returning vectors of i1 for a
>>>> while,
>>> the code generators don't know how to codegen vectors of i1, so does
>>> this actually work?
>> No, but there are no clients of them yet.
> 
> What's the proposed replacement that will be pattern-matched to the  
> vector comparison instructions in AltiVec, SSE, and NEON?

That's a good question. The LLVM IR representation is to use icmp and 
fcmp on vectors returning a vector of i1. The backend can store that as 
a vector of whatever MVT it likes.

I finished a patch to remove vicmp and vfcmp (I'll mail it to 
llvm-commits instead of spamming everyone here) and I had to XFAIL 9 
tests, two in CodeGen/X86 and seven in CodeGen/ARM. The two in X86 were 
from PRs filed by RapidMind who are using LLVM. The icmp/fcmp version 
should probably be supported first.

That said, having seen the existing VICmp and VFCmp implementation, I'm 
more motivated than ever to delete it. It's very buggy and is causing 
bugs in other places, like this one line .ll:

   global <4 x i1> icmp slt ( <4 x i32> <i32 1, i32 1, i32 1, i32 1>, <4 
x i32>  <i32 1, i32 2, i32 1, i32 2> ) ;

which llvm-as incorrectly rejects. And when you figure out why you 
should look at how the bitcode reader/writer decides when to use 
FUNC_CODE_INST_CMP vs. CMP2 and figure out how that ever worked at all...

Nick