1; RUN: llc < %s -asm-verbose=false -verify-machineinstrs -disable-wasm-fallthrough-return-opt -wasm-disable-explicit-locals -mattr=+simd128 | FileCheck %s
2
3; Regression test for an issue with patterns like the following:
4;
5;     t101: v4i32 = BUILD_VECTOR t99, t99, t99, t99
6;         t92: i32 = extract_vector_elt t101, Constant:i32<0>
7;             t89: i32 = sign_extend_inreg t92, ValueType:ch:i8
8;
9; Notice that the sign_extend_inreg has source value type i8 but the
10; extracted vector has type v4i32. There are no ISel patterns that
11; handle mismatched types like this, so we insert a bitcast before the
12; extract. This was previously an ISel failure. This test case is
13; reduced from a private user bug report, and the vector extracts are
14; optimized out via subsequent DAG combines.
15
16target datalayout = "e-m:e-p:32:32-i64:64-n32:64-S128"
17target triple = "wasm32-unknown-unknown"
18
19; CHECK-LABEL: foo:
20; CHECK:         .functype foo (i32) -> ()
21; Implementation omitted...
22; CHECK:         return
23define void @foo(<4 x i8>* %p) {
24  %1 = load <4 x i8>, <4 x i8>* %p
25  %2 = sitofp <4 x i8> %1 to <4 x double>
26  %3 = fmul <4 x double> zeroinitializer, %2
27  %4 = fadd <4 x double> %3, zeroinitializer
28  %5 = fptrunc <4 x double> %4 to <4 x float>
29  store <4 x float> %5, <4 x float>* undef
30  ret void
31}
32