search

rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
97.96k stars 12.68k forks source link

Intrinsic name not mangled correctly for type arguments #102738

Closed Nugine closed 1 year ago

Nugine commented 2 years ago

My project uses arm neon intrinsics. The arm test starts failing after 2022-10-04.

Reproduce:

git clone git@github.com:Nugine/simd.git
cd simd
cd crates/vsimd
export CARGO_INCREMENTAL=0
cross test --target armv7-unknown-linux-gnueabihf --no-default-features --features detect,unstable

https://github.com/Nugine/simd/actions/runs/3191907964/jobs/5214086504

+ cross test --target armv7-unknown-linux-gnueabihf --no-default-features --features detect,unstable
   Compiling vsimd v0.1.0-dev (/project/crates/vsimd)
Intrinsic name not mangled correctly for type arguments! Should be: llvm.arm.neon.vld1x2.v16i8.p0
ptr @llvm.arm.neon.vld1x2.v16i8.p0i8
in function _ZN4core9core_arch10arm_shared4neon9generated11vld1q_u8_x217hedb14b770e5be213E
LLVM ERROR: Broken function found, compilation aborted!
error: could not compile `vsimd`
error: Recipe `arm-test` failed with exit code 101

rustc 1.66.0-nightly (57f097ea2 2022-10-01) works.

rustc 1.66.0-nightly (c97d02cdb 2022-10-05) works (incremental compilation enabled) rustc 1.66.0-nightly (c97d02cdb 2022-10-05) fails (incremental compilation disabled)

I'm not sure how to find a MCVE for this issue, so I put the original context here.

Meta

rustc --version --verbose:

rustc 1.66.0-nightly (c97d02cdb 2022-10-05)
binary: rustc
commit-hash: c97d02cdb5ca5f5e9eff1fa9e4560d220d1fd2a0
commit-date: 2022-10-05
host: x86_64-unknown-linux-gnu
release: 1.66.0-nightly
LLVM version: 15.0.2
nikic commented 2 years ago

Looks like stdarch hardcodes LLVM intrinsic mangling in a few places. These should be changed from p0i8 to just p0 in LLVM 15: https://github.com/rust-lang/stdarch/search?q=p0i8

Usually this gets gracefully handled through intrinsic remangling, I don't know why that doesn't occur for your particular case. Updating stdarch to directly use the right names should avoid any problems though.

cc @Amanieu

Amanieu commented 2 years ago

@nikic Does this apply to all .p0* extensions or just .p0i8? For example llvm.aarch64.neon.ld4.v1f64.p0v1f64.

nikic commented 2 years ago

It applies to all .pN extensions.

Amanieu commented 2 years ago

Minimal reproduction on godbolt: https://rust.godbolt.org/z/v79M878Ye

@nikic Any idea why LLVM auto-upgrade isn't working in this case?

nikic commented 2 years ago

Thanks for the minimal reproducer. This turned out to be a simple typo, fixed in https://github.com/llvm/llvm-project/commit/c8938809d155682ef5eec170897b8c26b8cbf3ea. This was hidden when doing simple tests with opt because the IR parser was doing another redundant remangle (fixed in https://github.com/llvm/llvm-project/commit/d25ef09466e4e4ca807e85360812cf9d139c4249 and https://github.com/llvm/llvm-project/commit/befb731be64a60b97f857d18eaa40d68f8ba792d).

Backport request: https://github.com/llvm/llvm-project/issues/58522