[llvm-dev] InstructionSimplify: adding a hook for shufflevector instructions

Sanjay Patel via llvm-dev llvm-dev at lists.llvm.org
Thu Mar 30 10:53:38 PDT 2017


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.

On Thu, Mar 30, 2017 at 10:53 AM, Craig Topper <craig.topper at gmail.com>
wrote:

> 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.
>
> ~Craig
>
> On Thu, Mar 30, 2017 at 9:28 AM, Rackover, Zvi via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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
>>
>> *From:* Sanjay Patel [mailto:spatel at rotateright.com]
>> *Sent:* Thursday, March 30, 2017 18:31
>> *To:* Rackover, Zvi <zvi.rackover at intel.com>
>> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>
>> *Subject:* Re: InstructionSimplify: adding a hook for shufflevector
>> instructions
>>
>>
>>
>> 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.
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> Intel Israel (74) Limited
>>
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170330/5bd71766/attachment.html>


More information about the llvm-dev mailing list