[LLVMdev] Vector splitting vs widening

[Nadav Rotem]

>> The problem is essentially the following: there are no vector f32
>> types (yet), so the <v4i1> = setcc <v4f32> node needs to be split
>> and scalarized. The operand splitting seems to start correctly, but
>> because <v4i1> is itself a legal type, after splitting the node into
>> <v2i1> = setcc <v2f32>, the process becomes confused. The operands
>> are again split (as they should be), but it tries to widen the
>> <v2i1> result back to <v4i1> (thus hitting the operand assertion).
>> 
>> In some sense, the problem is that DAGTypeLegalizer::run decides what
>> to do solely based on the result of calling getTypeAction(ResultVT),
>> but it seems that in this case the operand types need to be
>> accounted for in this determination. Enhancing the logic there to
>> consider the result types in this case seems like it should be
>> straightforward, but how general a problem is this? [Can this
>> problem only happen with vsetcc nodes?]
>> 
>> 
>> 
>> 
>> If I understand your description correctly, the type" <v4i1> setcc
>> ..." is split into "<v2i1> setcc ..." because of the v4f32 operands,
>> but later on we decide to widen <v2i1> back to <v4i1> because we
>> legalize the result ?
> 
> The problem is not the widening itself, but that the widen-result code for setcc assumes that the operands have also just been widened (which here is not true, they've been split instead). FWIW, with the patch I attached, the operands are split, then scalarized, and I'm left with a vector setcc with two build_vector operands.
> 
>> Can you declare <v2i1> as a legal type ?
> 
> I'd have to write more load/store code, right? Why do you suggest this?
> 

How are you representing the v4i1 type on PPC64 ? Does it have mask registers ? I am surprised that we are not promoting the v4i1 to v4i32 or something similar. On NEON and SSE we promote llvm vector of booleans to the SIMD element and map it to the sign bit.

Thanks,
Nadav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130311/267c902d/attachment.html>