[PATCH] D76983: [InstCombine] Transform extractelement-trunc -> bitcast-extractelement

[Jeroen Dobbelaere via Phabricator via llvm-commits]

jeroen.dobbelaere added a comment.

This patch triggers a regression on our side:

For the following code:

  define dso_local <4 x i16> @truncate_v_v(<4 x i32> %lhs) #0 {
  entry:
    %vecext = extractelement <4 x i32> %lhs, i32 0
    %conv = trunc i32 %vecext to i16
    %vecinit = insertelement <4 x i16> undef, i16 %conv, i32 0
    %vecext1 = extractelement <4 x i32> %lhs, i32 1
    %conv2 = trunc i32 %vecext1 to i16
    %vecinit3 = insertelement <4 x i16> %vecinit, i16 %conv2, i32 1
    %vecext4 = extractelement <4 x i32> %lhs, i32 2
    %conv5 = trunc i32 %vecext4 to i16
    %vecinit6 = insertelement <4 x i16> %vecinit3, i16 %conv5, i32 2
    %vecext7 = extractelement <4 x i32> %lhs, i32 3
    %conv8 = trunc i32 %vecext7 to i16
    %vecinit9 = insertelement <4 x i16> %vecinit6, i16 %conv8, i32 3
    ret <4 x i16> %vecinit9
  }

The tests expects to see:

  define dso_local <4 x i16> @truncate_v_v(<4 x i32> %lhs) local_unnamed_addr #0 {
  entry:
    %0 = trunc <4 x i32> %lhs to <4 x i16>
    ret <4 x i16> %0
  }

which, in machine instructions, is mapped onto a vector trunc instruction.

But now, we see:

  define dso_local <4 x i16> @truncate_v_v(<4 x i32> %lhs) local_unnamed_addr #0 {
  entry:
    %0 = bitcast <4 x i32> %lhs to <8 x i16>
    %vecinit9 = shufflevector <8 x i16> %0, <8 x i16> undef, <4 x i32> <i32 0, i32 2, i32 4, i32 6>
    ret <4 x i16> %vecinit9
  }

which is expanded into a large sequence of code going through the stack.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76983/new/

https://reviews.llvm.org/D76983