Selecting Vector Shuffle of Different Types

Project Infrastructure LLVM Dev List Archives
1

The AVX saga continues.

I am attempting to write a pattern for VEXTRACTF128 but am having some
problems. My attempt looks something like this:

defm EXTRACTF128 : avx_fp_extract_vector_osta_node_mri_256<0x19, MRMDestReg,
                      MRMDestMem, "extractf128", undef, X86f32, X86i32i8,
                   // rr
                   [(set VR128:$dst,
                         (v4f32 (vector_shuffle
                                     (v8f32 undef), (v8f32 VR256:$src1),
                                     VEXTRACTF128_shuffle_mask:$src2)))]>;

(This is simplified for the sake of exposition but this gets the idea across).

TableGen reports a type contradition:

VEXTRACTF128_256mri: (st:isVoid (vector_shuffle:v4f32 (undef:v8f32),
VR256:v8f32:$src1, (build_vector)<<P:Predicate_VEXTRACTF128_shuffle_mask>>:
$src2), addr:iPTR:
$dst)<<P:Predicate_unindexedstore>><<P:Predicate_store>><<P:Predicate_alignedstore>>
tblgen: In VEXTRACTF128_256mri: Type inference contradiction found in node
vector_shuffle!

Well, it's right! So how do I express this kind of thing? Since LLVM 2.5
shufflevector supports creating a vector of a difference size than the
inputs. Which is exactly what we need for VEXTRACTF128 and VINSERTF128.

                               -Dave

2

I suppose I could add an extract_subreg to make TableGen happy about types.
This is already custom lowered so it wouldn't be hard to do. Is that the
correct approach here?

                                -Dave

3

I think the SelectionDAG vector_shuffle node still requires the vector types to match. The LLVM IR shuffles can have a different size, but they are forced to match when building the SelectionDAG.

4

Perhaps EXTRACT_SUBVECTOR would be more appropriate here?

-Eli

5

It would be really great if the SelectionDAG shuffle node had the same flexibility as the IR instruction, w.r.t. different sized inputs and outputs.

Nate

6

Except there's no upper 128-bit subvector of a ymm register, which is why we
need VEXTRACTF128 / VINSERTF128. It's a big pain in the rear.

                           -Dave