[LLVMdev] Vector splitting vs widening

[Hal Finkel]

----- Original Message -----
> From: "Nadav Rotem" <nrotem at apple.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu>
> Sent: Wednesday, March 6, 2013 3:40:50 PM
> Subject: Re: [LLVMdev] Vector splitting vs widening
> 
> Hi Hal,
> 
> 
> 
> 
> 
> 
> 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?

Thanks again,
Hal