llvm dev - Jan 2017 - IR canonicalization: shufflevector or vector trunc?

It's time for another round of "What is the canonical IR?"

Credit for this episode to Zvi and PR31551. :)
https://llvm.org/bugs/show_bug.cgi?id=31551


define <4 x i16> @shuffle(<16 x i16> %x) {
  %shuf = shufflevector <16 x i16> %x, <16 x i16> undef, <4 x
i32>
<i32 0, i32 4, i32 8, i32 12>
  ret <4 x i16> %shuf
}

define <4 x i16> @trunc(<16 x i16> %x) {
  %bc = bitcast <16 x i16> %x to <4 x i64>
  %tr = trunc <4 x i64> %bc to <4 x i16>
  ret <4 x i16> %tr
}

Potential reasons to prefer one or the other:
1. Shuffle is the most compact.
2. Trunc is easier to read.
3. One of these is easier for value tracking.
4. Compatibility with existing IR transforms (eg, InterleavedAccess
recognizes the shuffle form).
5. We don't create arbitrary shuffle masks in IR because that's bad for
a
lot of targets (but maybe this mask pattern should always be recognized as
special?).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170112/feacca26/attachment.html>

On 1/12/2017 9:04 AM, Sanjay Patel via llvm-dev wrote:
> It's time for another round of "What is the canonical IR?"
>
> Credit for this episode to Zvi and PR31551. :)
> https://llvm.org/bugs/show_bug.cgi?id=31551
> define <4 x i16> @shuffle(<16 x i16> %x) {
>    %shuf = shufflevector <16 x i16> %x, <16 x i16> undef, <4
x i32> <i32 0, i32 4, i32 8, i32 12>
>    ret <4 x i16> %shuf
> }
>
> define <4 x i16> @trunc(<16 x i16> %x) {
>    %bc = bitcast <16 x i16> %x to <4 x i64>
>    %tr = trunc <4 x i64> %bc to <4 x i16>
>    ret <4 x i16> %tr
> }
>
> Potential reasons to prefer one or the other:
> 1. Shuffle is the most compact.
> 2. Trunc is easier to read.
> 3. One of these is easier for value tracking.
> 4. Compatibility with existing IR transforms (eg, InterleavedAccess 
> recognizes the shuffle form).
> 5. We don't create arbitrary shuffle masks in IR because that's bad
> for a lot of targets (but maybe this mask pattern should always be 
> recognized as special?).
Hmm... not sure what the right answer is, but a couple more observations:
1. If we're going to canonicalize, we should probably canonicalize the 
same way independent of the original argument type (so we would 
introduce bitcasts either way).
2. Those two functions are only equivalent on little-endian platforms.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170112/d340211b/attachment.html>

On Thu, Jan 12, 2017 at 11:06 AM, Friedman, Eli <efriedma at
codeaurora.org>
wrote:
> On 1/12/2017 9:04 AM, Sanjay Patel via llvm-dev wrote:
>
> It's time for another round of "What is the canonical IR?"
>
> Credit for this episode to Zvi and PR31551. :)
> https://llvm.org/bugs/show_bug.cgi?id=31551
>
> define <4 x i16> @shuffle(<16 x i16> %x) {
>   %shuf = shufflevector <16 x i16> %x, <16 x i16> undef, <4
x i32> <i32 0, i32 4, i32 8, i32 12>
>   ret <4 x i16> %shuf
> }
>
> define <4 x i16> @trunc(<16 x i16> %x) {
>   %bc = bitcast <16 x i16> %x to <4 x i64>
>   %tr = trunc <4 x i64> %bc to <4 x i16>
>   ret <4 x i16> %tr
> }
>
>
> Potential reasons to prefer one or the other:
> 1. Shuffle is the most compact.
> 2. Trunc is easier to read.
> 3. One of these is easier for value tracking.
> 4. Compatibility with existing IR transforms (eg, InterleavedAccess
> recognizes the shuffle form).
> 5. We don't create arbitrary shuffle masks in IR because that's bad
for a
> lot of targets (but maybe this mask pattern should always be recognized as
> special?).
>
>
> Hmm... not sure what the right answer is, but a couple more observations:
> 1. If we're going to canonicalize, we should probably canonicalize the
> same way independent of the original argument type (so we would introduce
> bitcasts either way).
>
Ah, right - kill #1 in my list.

> 2. Those two functions are only equivalent on little-endian platforms.
>
I was wondering about that. So yes, if we do want to canonicalize (until
the recent compile-time complaints, I always thought this was the objective
of InstCombine...maybe it still is), then the masks we're matching or
generating will differ based on endianness.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170112/f0f7bdc6/attachment-0001.html>