https://bugs.llvm.org/show_bug.cgi?id=50507

            Bug ID: 50507
           Summary: wasm32: i8x16.bitmask return value assumes upper 16
                    bits may not be zero
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: WebAssembly
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected]

In the course of binding the i8x16.bitmask instruction for Rust some discussion
-- https://github.com/rust-lang/rust/issues/74372#issuecomment-848543931 --
brought up that an appropriate return value for this intrinsic would be u16
since it can only return 16 bits of data (and u8 for the other bitmask
intrinsics). When changing the intrinsics to do this, though, it generates an
unnecessary i32.and instruction to mask out the upper bits.

I believe the reason for this is that the intrinsics are declared in LLVM as
returning an i32 so when we cast that to an i16 in LLVM IR it causes the
general codegen mechanism for such a cast to kick in which masks away the upper
bits.

Basically this IR:


target triple = "wasm32"

declare i32 @llvm.wasm.bitmask.v16i8(<16 x i8>)

define zeroext i16 @foo(<4 x i32> %a) unnamed_addr #0 {
start:
  %0 = bitcast <4 x i32> %a to <16 x i8>
  %1 = tail call i32 @llvm.wasm.bitmask.v16i8(<16 x i8> %0)
  %2 = trunc i32 %1 to i16
  ret i16 %2
}

attributes #0 = { "target-features"="+simd128" }



produces (expectedly) the sequence:


        i8x16.bitmask
        i32.const       65535
        i32.and 


Could the intrisnic, however, be modified to return `i16`? Simlarly could the
other intrinsics be updated to return `i8`? I'm not sure if `i4` is well
supported but presumably if it works it could be used for `i32x4.bitmask`,
although for language binding purposes it'd be nice to also accept `i8` as a
return value for the intrinsic.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to