llvm::ShuffleVectorInst yields incorrect vector length in 2.6

Hi,

When I emit the llvm::ShuffleVectorInst instruction from my code generator
the result vector has the length of vector 1, instead of the element type of
vector 1 and the length of the mask vector;

  %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 documentation reads;

"The result of the instruction is a vector whose length is the same as the
shuffle mask and whose element type is the same as the element type of the
first two operands."

Is this a bug, or am I misusing the ShuffleVectorInst instruction?

Dumping the individual parameters before calling the ShuffleVectorInst
yields;

  %13 = load <3 x float>* %w ; <<3 x float>> [#uses=0]
<3 x float> undef
<2 x i32> <i32 1, i32 0>

Any suggesion? Thanks in advance!

Regards,

Maarten Hoeben

Hi,

When I emit the llvm::ShuffleVectorInst instruction from my code generator
the result vector has the length of vector 1, instead of the element type of
vector 1 and the length of the mask vector;

%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"?

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

. 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.

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?

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
>. 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.