Hi Wei,
I haven’t worked on LLVM codegen for several years now, so you’ll probably want to talk to someone who’s been involved with it more recently. Sending to llvm-dev@ was the right call.
+llvm-dev@ back in.
Having said that:
Those are the semantics of the SHUFFLE_VECTOR node, so the code is doing the right thing. See ISDOpcodes.h:
/// VECTOR_SHUFFLE(VEC1, VEC2) - Returns a vector, of the same type as
/// VEC1/VEC2. A VECTOR_SHUFFLE node also contains an array of constant int
/// values that indicate which value (or undef) each result element will
/// get. These constant ints are accessible through the
/// ShuffleVectorSDNode class. This is quite similar to the Altivec
/// ‘vperm’ instruction, except that the indices must be constants and are
/// in terms of the element size of VEC1/VEC2, not in terms of bytes.
If you’re asking why SHUFFLE_VECTOR was defined this way - I don’t know. This goes back to the very early days of LLVM and SelectionDAG (see https://reviews.llvm.org/rL26879). The reference to Altivec in the above comment is a good hint of how it ended up like this.
In any case, this does not necessarily make the generated code less efficient - this is just an intermediate representation. Every target supports its own (possibly very restricted, or very wide) set of vector operations, and targets try to pattern-match complex DAG patterns to their instructions. So you can get a target shuffle-like instruction even if the target-independent DAG does not have a SHUFFLE_VECTOR.
Michael