remove the simple_llvm_intrinsic wrappers

[thestinger]

This removes a layer of generated wrappers from native LLVM intrinsics
we can represent directly in the type system. There are a lot with i1
parameters so there's still a need for those to be in the compiler.

These are an implementation detail of the compiler, so the inconsistency
is worth the simplification and faster compiles.

[alexcrichton]

I've been on the fence about this for awhile. I think this is actually the third time I've seen this come up! I certainly like the negative diffstat on this, but I do think that there's a possibly major downside to this. As you've mentioned in #10008, none of these intrinsics are really unsafe at all (at least all the math ones). If we move to using link_name instead of compiler support, then there won't be any way to expose these as safe bindings to the equivalent LLVM functions.

It also seems a little odd to have half the intrinsics in the compiler and half of them using link_name, but that's not really a reason to not land this. What do you think about not being able to flag these as safe?

[thestinger]

@alexcrichton: I think forcing all extern block functions to unsafe should be done with a default deny lint check so the minority of foreign functions that are safe for all inputs can still be exposed as safe. Of course, this isn't going to work for automatically generated C bindings via libclang, but it will work for these.

#10267

C and LLVM functions don't match the Rust ABI since they're missing an environment pointer so for now you still do need a wrapper anyway... but at least most of those wrappers are already there to deal with the current unsafe issue. If we drop the environment pointer they can be directly exposed.

[alexcrichton]

Interesting, I feel like this pull request should have the same fate as #10267 in that case, I will nominate that for discussion.

[brson]

This does prevent the standard library from being built with a hypothetical non-LLVM backend (or at least the intrinsics need to be declared differently per backend).

[thestinger]

Yeah, it makes this implementation of the standard library less portable, but the core language definition becomes smaller so an alternate implementation would have a bit less to do.

I would like to feature-gate "rust-intrinsic" and #[link_name = "llvm.*"] and hide the numeric intrinsics as implementation details of the numeric modules. The interface could then be implemented as an LLVM intrinsic, libm call or gcc intrinsic without changing any user-visible APIs. I have an RFC open about part of this: #10008.

[emberian]

A hearty 👍 on this

[alexcrichton]

We have decided to close #10267, and as a result I agree with @brson that using the llvm.foo.bar names ties us a little too closely to LLVM if anyone ever wants to create another backend for rust. This isn't a huge burden in the compiler as intrinsics are well supported. As a result, I'm closing this.