Add integer to f16 conversions

[tgross35]

These are not present in LLVM's compiler-rt but LLVM does emit them in some cases 1.

[tgross35]

Includes #730 since PPC crashes without it.

[tgross35]

@quaternic would you mind double checking some of my logic here?

With this current implementation, we are getting errors like the following:

thread 'i_to_f::__floatunsihf' (15281862) panicked at builtins-test/tests/conv.rs:103:5:
incorrect rounding by __floatunsihf(2147483648): inf (0x7c00)
f->i bracket: (65504, 4294967295, 0)
errors: (2147418144, 2147483647, 2147483648)

Which is coming from the bit of code here https://github.com/tgross35/compiler-builtins/blob/c462b7b5aa56a2ff3cdbfaf7c19143bbdee17b00/builtins-test/tests/conv.rs#L44-L79. I think the implementation is correct, especially considering the tests against apfloat seem okay. So I think this is an error in the validation algorithm here, which only shows up for f16 because f16::MAX is way closer to 0 (NAN as i*) than to any iN::MAX for N >= 32 (all that we have algorithms for). And that isn't true for any other float type, even f32::MAX as u128 is > u128::MAX / 2.

As I'm typing it out that sounds pretty reasonable, just need to figure out how to patch this error algorithm.

[quaternic]

I think the validation logic is broken in that the apfloat-results that overflowed to infinity are converted back to an integer, specifically the maximum for the type, which should be irrelevant for the casting from integer to float.

The overflow threshold is specifically when the exponent after rounding exceeds the maximum. But the rounding itself is done as if the exponent was unbounded. So for f16:

[src/main.rs:4:5] f16::MAX.next_down() as f32 = 65472.0
[src/main.rs:5:5] f16::MAX as f32 = 65504.0
[src/main.rs:6:5] 65519 as f16 as f32 = 65504.0
[src/main.rs:7:5] 65520 as f16 as f32 = inf

65520 as f16 overflows because it would round to 65536.0 if the exponent range allowed.

[tgross35]

Isn't that represented correctly? The apfloat bit at https://github.com/tgross35/compiler-builtins/blob/c462b7b5aa56a2ff3cdbfaf7c19143bbdee17b00/builtins-test/tests/conv.rs#L29-L37 should be the same as this:

>> :dep rustc_apfloat
   Compiling rustc_apfloat v0.2.3+llvm-462a31f5a5ab
   Compiling smallvec v1.15.1
   Compiling bitflags v2.10.0
>> use rustc_apfloat::ieee::Half
>> use rustc_apfloat::Float;
>> Half::from_i128(65519)
StatusAnd { status: Status(INEXACT), value: 65504(Normal | +[2047] * 2^15) }
>> Half::from_i128(65519).value.to_bits()
31743
>> Half::from_i128(65520)
StatusAnd { status: Status(OVERFLOW | INEXACT), value: +Inf(Infinity | +[0] * 2^16) }
>> Half::from_i128(65520).value.to_bits()
31744

[quaternic]

Lines 48-50 as-cast the f16 values back to integers, which saturates inf to u32::MAX, and NaN to 0, which is where you get the printed line

f->i bracket: (65504, 4294967295, 0)

[tgross35]

Ah, by

the apfloat-results that overflowed to infinity

I thought you were referring to the test above that uses rustc_apfloat. It's probably fine to skip the error_plus < error part of the check if <$f_ty>::wrapping_add(f1.to_bits().wrapping_sub(1)) is infinite then, right?