Can't get the correct return type of llvm link

[SparrowLii]

Look the following implementation of vld1_s16_x2 neon instruction:
godbolt
the return type of vld1x2.v4i16.p0i16 should be {<4 x i16>, <4 x i16>}
But if we do a similar implementation in rust:
gotbolt
llvm will change the return type to the wrong [ 2 x <i8 x 8> ]. As a result, we cannot implement the vld1_s16_x2 instruction.

[bjorn3]

Except for the padding using the "unadjusted" abi and a tuple works:

#![feature(link_llvm_intrinsics, aarch64_target_feature, stdsimd, simd_ffi, repr_simd, arm_target_feature, platform_intrinsics, abi_unadjusted)]

#[cfg(target_arch = "aarch64")]
use core::arch::aarch64::*;

#[cfg(target_arch = "arm")]
use core::arch::arm::*;

pub struct int16x4x2_t(pub int16x4_t, pub int16x4_t);
pub unsafe fn vld1_s16_x2(ptr: *const i16) -> int16x4x2_t {
    #[allow(improper_ctypes)]
    extern "unadjusted" {
        #[cfg_attr(target_arch = "arm", link_name = "llvm.arm.neon.vld1x2.v4i16.p0i16")]
        #[cfg_attr(target_arch = "aarch64", link_name = "llvm.aarch64.neon.ld1x2.v4i16.p0i16")]
        fn vld1_s16_x2_(ptr: *const i16) -> (int16x4_t, int16x4_t);
    }
    let (a, b) = vld1_s16_x2_(ptr);
    int16x4x2_t(a, b)
}

Intrinsic has incorrect return type!
{ [0 x i64], <4 x i16>, [0 x i64], <4 x i16>, [0 x i64] } (i16*)* @llvm.aarch64.neon.ld1x2.v4i16.p0i16
in function _ZN7example11vld1_s16_x217h2e85ec3f6fc419e2E
LLVM ERROR: Broken function found, compilation aborted!

[Lokathor]

having a repr(rust) type as the output type of the inner function call seems pretty dodgy

[SparrowLii]

@Amanieu I think this is a llvm bug? Considering that it blocked the implementation of about 500 neon instructions, can we have a solution to it?

[Amanieu]

This is a bug in rustc: with the "unadjusted" ABI it should emit the type in LLVM IR without padding. However I am not very familiar with this part of rustc so I'm not exactly sure what the best way to go about fixing it is.

[bjorn3]

The "unadjusted" ABI is just that. It directly uses the LLVM type rustc chose for the argument/return type for normal use inside the function without adjusting it for any calling convention as the argument/return type at LLVM level. This means that if rustc changes the representation of types at LLVM level, the "unadjusted" ABI changes too. The padding is not necessary in this case I think and as such could be removed, but there is no guarantee that there will never be padding. Luckily it is fine for stdarch to depend on unstable implementation details as it is shipped with a specific rustc version.