llvm dev - Mar 2017 - InstructionSimplify: adding a hook for shufflevector instructions

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170330/431a8637/attachment.html>

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>

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>