On Fri, Feb 20, 2026 at 01:44:27PM +0800, Max Chou wrote:
> On 2026-02-16 15:30, Richard Henderson wrote:
> > It doesn't feel right doing this here, because true overflow is handled
> > elsewhere. This is re-packing a FloatParts for a given FloatFmt.
> >
> > Perhaps parts64_float_to_float() would be the proper place for this, as
> > that's the conversion operation, and recognizing this overflow feels like
> > part of a conversion.
>
> Hmm, I agree with you. Maybe we could add a new float_to_e5m2 similar to
> float_to_ahp and replacing the parts_float_to_float calls in
> float32_to_float8_e5m2/bfloat16_to_float8_e5m2.
>
> +static void parts_float_to_e5m2(FloatParts64 *a, float_status *s,
> + bool saturate)
> +{
> + switch (a->cls) {
> + case float_class_snan:
> + case float_class_qnan:
> + parts_return_nan(a, s);
> + break;
> + case float_class_inf:
> + if (saturate) {
> + float_raise(float_flag_invalid, s);
> + a->cls = float_class_normal;
> + a->exp = float8_e5m2_params.exp_max - 1;
> + a->frac = MAKE_64BIT_MASK(float8_e5m2_params.frac_shift,
> + float8_e5m2_params.frac_size + 1);
> + }
> + break;
> + case float_class_denormal:
> + float_raise(float_flag_input_denormal_used, s);
> + break;
> + case float_class_normal:
> + case float_class_zero:
> + break;
> + default:
> + g_assert_not_reached();
> + }
> +}
>
Hi rnax,
This approach looks good to me. Adding a dedicated parts_float_to_e5m2
following the float_to_ahp pattern makes sense -- it keeps the infinity
saturation logic in the conversion path where it belongs, rather than in
the generic uncanon_sat repacking.
Thanks,
Chao
> Thanks for the feedbacks,
> rnax
>
