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

[Craig Topper via llvm-dev]

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/a676c1c5/attachment-0001.html>