Presence of `f16` in signatures causes missing symbols on PPC

[tgross35]

It seems like some function signatures make PowerPC targets require __gnu_f2h_ieee or __gnu_h2f_ieee even when they wouldn't be used. For example, attempting to build this test function:

#[test]
fn demo() {
    fuzz_float(N, |x: f32|
        let _tmp0: f16 = (|_x: f32| todo!())(x);
    });
}

gives a linker error looking for __gnu_f2h_ieee. Replacing the inner line with let _tmp0: f16 = todo!(); makes them go away. It seems like this is causing CI failures like https://github.com/rust-lang/compiler-builtins/actions/runs/10225081035/job/28293642361?pr=652 since we no longer build the C version.

I'll disable the tests for now, just making this issue to remember to re-enable them once our version of the symbols is available again.

Checked on powerpc64-unknown-linux-gnu with the 2024-08-02 nightly.

[beetrees]

This is caused by llvm/llvm-project#97981. On targets that use LLVM's miscompilation-inducing TypePromoteFloat f16 legalisation, LLVM defaults to passing/returning f16s as f32s unless the target says otherwise, meaning that casts are inserted even when no casts or f16 operations are present in the LLVM IR. A correct TypeSoftPromoteHalf lowering has been implemented that defaults to passing/returning f16 the same way as i16 but as TypePromoteFloat remains the default many backends are still using it.

[tgross35]

Closing this since I don't think there is anything to do here, thanks for the extra info.