[LLVMdev] llvm::ShuffleVectorInst yields incorrect vector length in 2.6

Bob Wilson bob.wilson at apple.com
Tue Feb 2 09:54:44 PST 2010


On Feb 2, 2010, at 9:24 AM, Maarten Hoeben wrote:

> 
> 
> Bob Wilson-3 wrote:
>> 
>>> 
>>> %13 = load <3 x float>* %w                      ; <<3 x float>>
>>> [#uses=0]
>>> %14 = shufflevector <3 x float> %13, <3 x float> undef, <2 x i32> <i32
>>> 1,
>>> i32 0> ; <<3 x float>> [#uses=0]
>> 
>> The type of %14 should be <2 x float>, since the elements are floats and
>> the mask has 2 entries.  What do you mean when you write that it has "the
>> length of vector 1"?
>> 
> 
> By length of "the length of vector 1" I meant ShuffleVectorInst yields a
> vector value with the same number of elements as the first argument (or
> second for that matter - they should be the same). In other words it returns
> a vector <3 x float>. From the documentation I understood, and your answers
> confirms, that it should return a vector of type <2 x float>. %14 is a
> direct dump of the value returned from the statement "new
> ShuffleVectorInst(...)", and it says it returned a vector of type <3 x
> float>. This is later confirmed by an assertion in the DAG code (I believe
> in a function visitShuffleVectorInst), complaining an incorrect number of
> elements for some type.

The code you sent does not show that it returns a type of <3 x float>.  Where are you seeing that?

> 
> My question is whether I misunderstood the documentation, or that there is a
> bug in the code generation. Apparently I didn't misread the documentation,
> but I find it hard to believe that the code generation is buggy. Any
> suggestion where I should look to diagnose this further?

llvm IR allows the shuffle mask to have a different number of elements than the source vectors, but the shuffle DAG node in codegen does not yet support that.  The DAG requires the mask to be the same length as the source vectors.  The IR should be legalized to conform to that, but in my experience, the resulting code is pretty horrible.  I'm sure it hasn't been exercised much so it's quite possible that it is also buggy.



More information about the llvm-dev mailing list