Revert #132662 to fix regression on targets without f128 support

[taiki-e]

This reverts #132662.

See #133035 for details of the regression.

Fixes #133035

r? @tgross35 @RalfJung

[rustbot]

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @rust-lang/wg-const-eval

[tgross35]

Thanks for putting the revert up. Ideally we would fix this in the compiler...

@bors r+

[bors]

📌 Commit 0a370d8 has been approved by tgross35

It is now in the queue for this repository.

[RalfJung]

@bors r-

I don't think we should revert a tier 1 perf fix in favor of a tier 3 target.

[RalfJung]

The deal with tier 3 targets is that they can tag along as long as they don't cause problems for our primary targets. But when a target needs a specific work-around, that needs to be done without undue cost for tier 1 targets.

[RalfJung]

Also, f16_f128 is a nighty feature, and it shouldn't unduly impact stable releases either.

Fixing this in the compiler isn't even very hard. Somewhere around here, we can iterate the function arguments, and if any of them has type f16 or f128 we can mark the function as inline. That's not a complete fix (e.g. when a float is wrapped in a newtype), but should be enough for this issue.

[taiki-e]

@RalfJung This is actually not tier 3 targets only. At least one of tier 2 target is also affected.

$ cargo build -Z build-std=core --target arm64ec-pc-windows-msvc
   Compiling core v0.0.0 (/Users/taiki/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/src/rust/library/core)
   Compiling compiler_builtins v0.1.138
   Compiling rustc-std-workspace-core v1.99.0 (/Users/taiki/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/src/rust/library/rustc-std-workspace-core)
error: could not compile `core` (lib)
rustc-LLVM ERROR: Only 32 and 64 bit floating points are supported for ARM64EC thunks

As said in #133035:

I suspect the same problem exists with the other targets listed here: https://github.com/rust-lang/compiler-builtins/blob/a09218f1c4d23ffbd97d68f0fefb5feed2469dc5/configure.rs#L82-L91

[tgross35]

The list of T1 and T2 targets that have either a selection or link failure is pretty extensive (including arm64ec, s390x, sparc, powerpc, wasm, anything cranelift), I didn't realize that would be re-exposed via #132662. It seems worth reverting, adding the compiler automatic inline (I'll work on that now) and then re-landing.

[taiki-e]

Fixing this in the compiler isn't even very hard. Somewhere around here, we can iterate the function arguments, and if any of them has type f16 or f128 we can mark the function as inline. That's not a complete fix (e.g. when a float is wrapped in a newtype), but should be enough for this issue.

I'm not sure if this really works; My understanding is that normal #[inline] only works if optimization is enabled, but as mentioned in #133035, I could reproduce the problem only when optimization was disabled:

Workaround: Passing --release flag resolves error.

[RalfJung]

I'm not sure if this really works; My understanding is that normal #[inline] only works if optimization is enabled, but as mentioned in #133035, I could reproduce the problem only when optimization was disabled:

#[inline], with or without optimizations, has the effect of suppressing codegen of the function if it's not actually called. That's what works around the selection bugs here.

At least one of tier 2 target is also affected.

But only with -Zbuild-std. The std we ship seems to be working fine?

[workingjubilee]

-Zbuild-std is also a nightly feature and it is well-known that the defaults for building the core and compiler builtins need to be different than they actually are set.

[tgross35]

I have a wip for the compiler change at #133050