Update LLVM intrinsic names for LLVM 15

[Amanieu]

LLVM 15 removes the pointer type from intrinsic suffixes, effectively replacing .p0i8 (and other similar types) with just .p0.

cc rust-lang/rust#102738

[rust-highfive]

@Amanieu: no appropriate reviewer found, use r? to override

[bjorn3]

This breaks rustc linked against older LLVM, right? We still support LLVM 13 and up.

[Amanieu]

It does unfortunately. According to @nikic LLVM should be automatically translating the builtins to their new name, but this doesn't seem to work correctly in some cases. Maybe this should be fixed in LLVM instead?

[bjorn3]

Does that translation only apply for loading bitcode generated by older LLVM versions maybe?

[nikic]

Does that translation only apply for loading bitcode generated by older LLVM versions maybe?

Generally yes, but we also apply it manually here: https://github.com/rust-lang/rust/blob/fa0ca783f89a83046e6ce0383385ba5b28296435/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp#L880-L882

[Amanieu]

I just looked at the code for UpgradeCallsToIntrinsic and it doesn't seem to do any renaming to remove pointer types from the intrinsic name. Pointer types seem to work for some intrinsics, like llvm.arm.ldrex.p0i32, but not others like llvm.arm.neon.vld1x2.v16i8.p0i8.

[nikic]

I just looked at the code for UpgradeCallsToIntrinsic and it doesn't seem to do any renaming to remove pointer types from the intrinsic name.

The renaming happens here: https://github.com/llvm/llvm-project/blob/096f93e73dc3f88636cdcb57515e3732385b452d/llvm/lib/IR/AutoUpgrade.cpp#L1088

Pointer types seem to work for some intrinsics, like llvm.arm.ldrex.p0i32, but not others like llvm.arm.neon.vld1x2.v16i8.p0i8.

Hm, possibly somehow related to the latter using a LLVMAnyPointerType<LLVMMatchType<0>> type, while the former uses llvm_anyptr_ty.

[nikic]

Auto-upgrade seems to work fine with opt, both with and without a simultaneous upgrade of the return type: https://llvm.godbolt.org/z/Mz6cKbPh1

[Amanieu]

It seems that this should be handled in LLVM. I'm going to close this PR, discussion should continue in rust-lang/rust#102738.