Support unsafe float-to-int casts

[RalfJung]

With rust-lang/rust#66841, we have some unsafe intrinsics to float-to-int casts. We should implement those in Miri, with appropriate UB checking of course. So we need to figure out how to check, with apfloat, if the cast would go wrong.

We also should check that the float-to-int "as" casts in Miri match the planned safe behavior in Rust. I am not sure what those plans currently are, probably whatever -Z saturating-float-casts does. @eddyb the from_i128/from_u128 methods in apfloat, are they saturating? (rust-lang/rust#70437, #1265)

[RalfJung]

The docs for the apfloat cast method says

In case of an invalid operation exception, deterministic values are returned, namely zero for NaNs and the minimal or maximal value respectively for underflow or overflow.

So, it seems like our "as" implementation matches -Z saturating-float-casts?

[eddyb]

@hanna-kruppe is the expert here, but that sounds right to me.

[hanna-kruppe]

Yes, the behavior in that quote matches the runtime behavior with -Z saturating-float-casts, assuming underflow means "negative value outside the range of destination type" (like overflow, just with opposite sign) rather than the condition called underflow in IEEE 754 (magnitude too close to zero, regardless of sign).

[RalfJung]

assuming underflow means "negative value outside the range of destination type" (like overflow, just with opposite sign) rather than the condition called underflow in IEEE 754 (magnitude too close to zero, regardless of sign)

Hm... sounds like a reasonable interpretation, but it's a bit worrying that terminology doesn't match up.

[RalfJung]

Okay, with #1265 it seems like our cast story is correct (except for the NaN issue tracked at rust-lang/rust#69532). I confirmed locally that this matches behavior of rustc with -Zmir-opt-level=0 -Zsaturating-float-casts.

What remains is the unsafe intrinsic, where the hard part is the UB checking. How do we detect if casting the float to the target int type overflowed or not?
We could rather crudely compare the result to the max/min value of the target type, but I assume that's wrong -- we could hit that value regularly, not as result of saturation.

The safety docs for these methods say the input must "be representable in the return type Int, after truncating off its fractional part". Doesn't that mean that if u64::MAX as f64 rounds up, the result may not be used with these methods? (It seems to round down, but that might not be the case for all possible casts.)
Cc @SimonSapin

We could also compare the input with u64::MAX as f64 (if we are currently doing f64 -> u64 casting), and reject it if it is bigger. But I assume that is incorrect, because u64::MAX as f64 is 18446744073709551615, and 18446744073709551616 is still smaller than u64::MAX and thus a legal input. OTOH, that number is not representable I guess, otherwise the cast would not have rounded down quite so far... but for smaller types this certainly doesn't work; 255.5f64 as u8 is legal according to what the docs say, but it is bigger than u8::MAX as f64.

[hanna-kruppe]

I believe the simplest way (for miri) is:

1. Perform the "drop the fractional bits" part first. This should be rustc_apfloat's round_to_integral with rounding to zero.
2. Cast the truncated float to u128 and compare that against the target type's range. You'll still need to check that the float value wasn't out of range for u128, but since the fractional bits were already dropped in the first step, the is_exact output parameter will tell you if the "integer part" fit into u128.

The conversion to u128 has no equivalent for signed types but waves hand splitting the float into (sign, absolute value) should solve that. Should not be a conceptual challenge, this kind of trick just often leads to extra bookkeeping that can be annoying to spell out (which is why I hand-wave it here).

[hanna-kruppe]

Cast the truncated float to u128 and compare that against the target type's range. You'll still need to check that the float value wasn't out of range for u128, but since the fractional bits were already dropped in the first step, the is_exact output parameter will tell you if the "integer part" fit into u128.

Actually, just casting to the right bit width to begin with should work just fine (for unsigned types; again signed types need extra care). The cast needs to perform the integer range check anyway, and for reasons described above is_exact should tell you precisely if it was out of range.

[RalfJung]

For signed casts, why would to_i128 not work just as well as to_u128 works for unsigned?

For is_exact, there actually seem to be two ways to determine this? There's the &mut bool: is_exact in the _r variants of the cast methods, but the returned Status also has an INEXACT flag.

[RalfJung]

Cast the truncated float to u128

So there will never be a problem where truncation to an integer leads to more rounding loss, or so? The truncation operation is always exactly representable?