[llvm-commits] [llvm] r74964 - in /llvm/trunk: lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp test/CodeGen/X86/vec_compare.ll

[Chris Lattner]

On Jul 7, 2009, at 7:38 PM, Eli Friedman wrote:

> On Tue, Jul 7, 2009 at 7:16 PM, Eli Friedman<eli.friedman at gmail.com>  
> wrote:
>> On Tue, Jul 7, 2009 at 6:29 PM, Dan Gohman<gohman at apple.com> wrote:
>>> EXTRACT_SUBVECTOR is normally used to extract a legal value from
>>> an illegal one. The code above does the opposite, extracting a
>>> potentially illegal value from a legal one.
>>
>> As far as I can tell, we support both cases properly in type
>> legalization; what specific case breaks?
>
> Mmm, nevermind, you're talking about something like the following?
>
> define void @test2(<2 x i32> %A, <2 x i32> %B, <2 x i32>* %C)  
> nounwind {
>       %D = icmp sgt <2 x i32> %A, %B
>       %E = zext <2 x i1> %D to <2 x i32>
>       store <2 x i32> %E, <2 x i32>* %C
>       ret void
> }
>
> It's really just falling apart because we don't support various
> related cases correctly; first, it hits the "Unimp" assert in this
> patch,  and if you just comment it out (which seems like the right
> thing to do), we hit an assertion because we don't support extracting
> an i1 from a <2 x i1> in PromoteIntRes_EXTRACT_VECTOR_ELT .  Still
> nothing going wrong with EXTRACT_SUBVECTOR.

Right, "what Eli said".  :)  Type legalization is inherently  
iterative, so producing illegal EXTRACT_SUBVECTOR's is not a problem.   
I don't claim that vector comparisons are perfect, in practice they  
are really only trustworthy for native datatypes right now.  This is  
the same situation as VSETCC.  It would be great to improve this, of  
course, but that was unrelated to slaying v[fi]cmp, so I didn't tackle  
it.

-Chris