Tracking issue for `link_llvm_intrinsics`

[aturon]

Tracks stabilization for the link_llvm_intrinsics feature, used via #[link_name="llvm.*"].

Edit: As this is obviously back-end specific, it will most likely never be stabilized.

[eefriedman]

We should just kill this off; there aren't any in-tree users, and it would be impossible to stabilize because LLVM doesn't make any stability promises about intrinsics.

[gnzlbg]

I am using link_llvm_intrinsics to work around missing intrinsics in rustc.

Some of these intrinsics belong in rustc, but even those would either remain unstable for a long period of time, or never be stabilized. This feature allows using these intrinsics out of tree for the benefit of the users of a nightly compiler (performance-wise).

[cramertj]

@gnzlbg @jonhoo Are you still using this feature? Can it be removed?

[jonhoo]

I've since switched to std::instrinsics::prefetch_read, but I believe @aweinstock314's prefetch crate still depends on it.

[cramertj]

@aweinstock314 Are you still actively using this feature?

[gnzlbg]

@cramertj the stdsimd crate uses this feature for basically every single intrinsic. So, yes, we are using this feature, and using it more every day. Pinging: @alexcrichton .

The idea is to move the stdsimd crate into std and core, as a way to provide the functionality this feature gives to stable users. The prefetch crate can then be ported to use stdsimd and will work on stable. Maybe one could ping its author to see if they could already port to the stdsimd crate.

[alexcrichton]

@cramertj @gnzlbg afaik this feature cannot be removed because it's being used to implement the standard library (and also the stdsimd crate destined for libstd). I'd pesonally see this as a perma-unstable issue.

[gnzlbg]

Is there a way to make features usable only in std ?

[SimonSapin]

Some unstable features are named something_internals to indicate that they’re an implementation detail and not on the path to stabilization. But a determined Nightly user can still write #![feature(something_internals)] and use them.

[scottmcm]

FWIW, this was really convenient as a way to try out whether an LLVM intrinsic is even helpful before doing all the work to make and propose a rustc intrinsic for it.

[aweinstock314]

I'm using this in https://crates.io/crates/prefetch, as mentioned; I'm also using it (through https://crates.io/crates/llvmint) in https://github.com/aweinstock314/libgarble-rust for AES-NI (inline assembly was generating suboptimal assembly relative to intrinsics). I don't think my usage depends on them being eventually stabilised, so the _internals feature flag would satisfy my usage.

[gnzlbg]

The AES-NI intrinsics might become stabilized in the future via stdsimd (see rust-lang-nursery/stdsimd#295). The stdsimd crate provides some prefetching intrinsics already, but maybe the LLVM prefetch intrinsic should be exposed in core::intrinsic.

[scottmcm]

As a concrete example of why I'd like this to stick around as forever-unstable, I could do the following to experiment with the new intrinsics mentioned in #55286 without a code change:

#![feature(link_llvm_intrinsics)]
extern {
    #[link_name="llvm.sadd.sat.i32"]
    fn add_sat_i32(x: i32, y: i32) -> i32;
    #[link_name="llvm.uadd.sat.i32"]
    fn add_sat_u32(x: u32, y: u32) -> u32;
}
pub unsafe fn test_sfold(x: i32) -> i32 {
    add_sat_i32(add_sat_i32(x, 10), 20)
}
pub unsafe fn test_ufold(x: u32) -> u32 {
    add_sat_u32(add_sat_u32(x, 10), 20)
}