InstructionSimplify: adding a hook for shufflevector instructions

Project Infrastructure LLVM Dev List Archives
1

As Sanjay noted in D31426, InstructionSimplify is missing the following simplification:

This function:

define <4 x i32> @splat_operand(<4 x i32> %x) {

%splat = shufflevector <4 x i32> %x, <4 x i32> undef, <4 x i32> zeroinitializer

%shuf = shufflevector <4 x i32> %splat, <4 x i32> undef, <4 x i32> <i32 0, i32 3, i32 2, i32 1>

ret <4 x i32> %shuf

}

can be simplified to:

define <4 x i32> @splat_operand(<4 x i32> %x) {

%shuf = shufflevector <4 x i32> %x, <4 x i32> undef, <4 x i32> zeroinitializer

ret <4 x i32> %shuf

}

InstCombine covers this case inefficiently.

I noticed that InstructionSimplify does not do any simplifications for shufflevector’s other than constant folding. I just wanted to be sure there is no compelling reason for this before I start streaming patches. I assume that this is not related to our conservative approach of refraining from creation of new shuffle masks that may hurt some target.

Here are some more opportunities that can be added to InstructionSimplify, all of which are covered by InstCombine:

define <4 x i32> @undef_mask(<4 x i32> %x) {

%shuf = shufflevector <4 x i32> %x, <4 x i32> undef, <4 x i32> undef

ret <4 x i32> %shuf

}

à

define <4 x i32> @undef_mask(<4 x i32> %x) {

ret <4 x i32> undef

}

define <4 x i32> @identity_mask_0(<4 x i32> %x) {

%shuf = shufflevector <4 x i32> %x, <4 x i32> undef, <4 x i32> <i32 0, i32 1, i32 2, i32 3>

ret <4 x i32> %shuf

}

à

define <4 x i32> @identity_mask_0(<4 x i32> %x) {

ret <4 x i32> %x

}

define <4 x i32> @identity_mask_1(<4 x i32> %x) {

%shuf = shufflevector <4 x i32> undef, <4 x i32> %x, <4 x i32> <i32 4, i32 5, i32 6, i32 7>

ret <4 x i32> %shuf

}

à

define <4 x i32> @identity_mask_1(<4 x i32> %x) {

ret <4 x i32> %x

}

define <4 x i32> @pseudo_identity_mask(<4 x i32> %x) {

%shuf = shufflevector <4 x i32> %x, <4 x i32> %x, <4 x i32> <i32 0, i32 1, i32 2, i32 7>

ret <4 x i32> %shuf

}

à

define <4 x i32> @pseudo_identity_mask(<4 x i32> %x) {

ret <4 x i32> %x

}

define <4 x i32> @const_operand(<4 x i32> %x) {

%shuf = shufflevector <4 x i32> <i32 42, i32 43, i32 44, i32 45>, <4 x i32> %x, <4 x i32> <i32 0, i32 3, i32 2, i32 1>

ret <4 x i32> %shuf

}

à

define <4 x i32> @const_operand(<4 x i32> %x) {

ret <4 x i32> <i32 42, i32 45, i32 44, i32 43>

}

define <4 x i32> @merge(<4 x i32> %x) {

%lower = shufflevector <4 x i32> %x, <4 x i32> undef, <2 x i32> <i32 1, i32 0>

%upper = shufflevector <4 x i32> %x, <4 x i32> undef, <2 x i32> <i32 2, i32 3>

%merged = shufflevector <2 x i32> %upper, <2 x i32> %lower, <4 x i32> <i32 3, i32 2, i32 0, i32 1>

ret <4 x i32> %merged

}

à

define <4 x i32> @merge(<4 x i32> %x) {

ret <4 x i32> %x

}

Would appreciate your comments and feedback.

Thanks, Zvi

2

My grasp of LLVM history isn’t great, but I think these are missing because there wasn’t much need for vector optimization in IR because there just weren’t that many vector opportunities in IR. Ie, the vectorizers are relatively new, and hand-written vector code (eg, SSE intrinsics in source) generally went straight to the backend as target-specific IR intrinsics.

Now that we’re vectorizing more aggressively (and plan to do even more) and we’re converting target-specific vector source to generic vector IR whenever possible, it makes sense to add these kinds of optimizations.

One frequently visible sign of scalar privilege in instcombine is the use of “m_ConstantInt”. In many cases, this can be converted to “m_APInt” without much effort, and the transform will auto-magically apply to splat vector constants too.

3

Thanks, Sanjay, that makes sense. The opportunity for improving instcombining splat sounds promising.

Another question about shuffle simplification. This is a testcase from test/Transforms/InstCombine/vec_shuffle.ll:

define <4 x i32> @test10(<4 x i32> %tmp5) nounwind {

%tmp6 = shufflevector <4 x i32> %tmp5, <4 x i32> undef, <4 x i32> <i32 1, i32 undef, i32 undef, i32 undef>

%tmp7 = shufflevector <4 x i32> %tmp6, <4 x i32> undef, <4 x i32> zeroinitializer

ret <4 x i32> %tmp7

}

opt –instcombine will combine to:

define <4 x i32> @test10(<4 x i32> %tmp5) nounwind {

%tmp7 = shufflevector <4 x i32> %tmp5, <4 x i32> undef, <4 x i32> <i32 1, i32 1, i32 1, i32 1>

ret <4 x i32> %tmp7

}

Would it be ok to simplify the original function to the following?

define <4 x i32> @test10(<4 x i32> %tmp5) nounwind {

%tmp7 = shufflevector <4 x i32> %tmp5, <4 x i32> undef, <4 x i32> <i32 1, i32 undef, i32 undef, i32 undef>

ret <4 x i32> %tmp7

}

If the function is required to return a splat value, then I believe the answer is no, because the undef indices allow returning a value that is not a splat.

Thanks, Zvi

4

Zvi, for your test10 case. Isn’t the second shuffle splatting element 0 from the first shuffle. And the first shuffle puts element 1 of %tmp5 into element 0. So the correct final result is a splat of element 1 of %tmp5. The undef elements of the first shuffle are never consumed.

5

Sounds right. A splat-of-shuffle can be folded to a new splat, but this is different than a shuffle-of-splat which can eliminate the shuffle.

One thing I noticed in a recent instcombine patch: the IR version of “isSplat” doesn’t consider undef elements. The DAG version does. It would be nice to share that logic in some common util function.