[llvm-dev] IR canonicalization: shufflevector or vector trunc?

[Sanjay Patel via llvm-dev]

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>