remove the portable simd f16 patch

[folkertdev]

I believe this will fail but let's see what happens.

[folkertdev]

As expected

https://triage.rust-lang.org/gha-logs/rust-lang/rustc_codegen_cranelift/86638749132?pr=1675

  = note: C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/15.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:\a\rustc_codegen_cranelift\rustc_codegen_cranelift\build\portable-simd_target\x86_64-pc-windows-gnu\debug\deps\libproptest-f4ca5451e39982af.rlib(proptest-f4ca5451e39982af.proptest.26d0c0f6a929e698-cgu.05.rcgu.o):proptest.26d0c0f6a929e698-cgu.05.o:(.rdata$.refptr+0x0): undefined reference to `floorf16'
          C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/15.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:\a\rustc_codegen_cranelift\rustc_codegen_cranelift\build\portable-simd_target\x86_64-pc-windows-gnu\debug\deps\libproptest-f4ca5451e39982af.rlib(proptest-f4ca5451e39982af.proptest.26d0c0f6a929e698-cgu.05.rcgu.o):proptest.26d0c0f6a929e698-cgu.05.o:(.rdata$.refptr+0x0): undefined reference to `ceilf16'
          collect2.exe: error: ld returned 1 exit status

So that means we additionally need fallbacks for floorf16 and ceilf16. I'll look into that, seems straightforward.

[folkertdev]

This is still missing the return false, // has a fallback via f32s that #1674 adds for some of the other functions

[folkertdev]

Hmm, the changes here are good, but I think we need the the additional gates I added. those are merged into portable_simd but not yet synced.

[folkertdev]

I think this needs one more sync, rust-lang/rust#159582 should be in today's nightly.

[bjorn3]

I've done a sync again.

[folkertdev]

Hmm, this fails on non-windows now because it tries to perform f16 SIMD operations. For f32 and f64 this performs libcalls

            simd_for_each_lane(fx, a, ret, &|fx, lane_ty, _ret_lane_ty, lane| {
                let lane_ty = match lane_ty.kind() {
                    ty::Float(FloatTy::F32) => types::F32,
                    ty::Float(FloatTy::F64) => types::F64,
                    _ => unreachable!("{:?}", lane_ty),
                };
                let name = match (intrinsic, lane_ty) {
                    (sym::simd_fsin, types::F32) => "sinf",
                    (sym::simd_fsin, types::F64) => "sin",
                    (sym::simd_fcos, types::F32) => "cosf",
                    (sym::simd_fcos, types::F64) => "cos",
                    (sym::simd_fexp, types::F32) => "expf",
                    (sym::simd_fexp, types::F64) => "exp",
                    (sym::simd_fexp2, types::F32) => "exp2f",
                    (sym::simd_fexp2, types::F64) => "exp2",
                    (sym::simd_flog, types::F32) => "logf",
                    (sym::simd_flog, types::F64) => "log",
                    (sym::simd_flog10, types::F32) => "log10f",
                    (sym::simd_flog10, types::F64) => "log10",
                    (sym::simd_flog2, types::F32) => "log2f",
                    (sym::simd_flog2, types::F64) => "log2",
                    (sym::simd_round, types::F32) => "roundf",
                    (sym::simd_round, types::F64) => "round",
                    (sym::simd_round_ties_even, types::F32) => "rintf",
                    (sym::simd_round_ties_even, types::F64) => "rint",
                    _ => unreachable!("{:?}", intrinsic),
                };
                fx.lib_call(
                    name,
                    vec![AbiParam::new(lane_ty)],
                    vec![AbiParam::new(lane_ty)],
                    &[lane],
                )[0]
            });

But for f16 we want to instead call the fallback body. In fact, perhaps we always want to call the fallback body now, given that it exists. Is there any way to do that from within this code?

[folkertdev]

I guess we also need rust-lang/portable-simd#544.

[bjorn3]

I guess we also need rust-lang/portable-simd#544.

We could have a patch for that until it lands and gets synced to the rust-lang/rust repo. That would allow getting rid of the bulk of the portable-simd patch without having to wait for that PR.

[bjorn3]

CI passed 🎉

[folkertdev]

that works, that smaller patch should be much easier to maintain and hopefully we can get rid of it completely in the coming days.

[bjorn3]

Thanks a lot for working on this!

View changes since this review

[RalfJung]

Does that do the right thing for the "round" intrinsics?

[folkertdev]

I think so, every f16 value is representable in f32, and the resulting integer was already in an f16 so that should be fine too?

We do the same thing with the fallbacks in core.

[RalfJung]

every f16 value is representable in f32,

Yeah but not vice versa. So couldn't it be that this rounds to an integer that is representible in f32 but not f16, and then the second rounding goes wrong?