On Sat, 25 Jan 2025 at 16:42, Richard Henderson
<richard.hender...@linaro.org> wrote:
>
> On 1/24/25 08:27, Peter Maydell wrote:
> > Currently we handle flushing of output denormals in uncanon_normal
> > always before we deal with rounding.  This works for architectures
> > that detect tininess before rounding, but is usually not the right
> > place when the architecture detects tininess after rounding.  For
> > example, for x86 the SDM states that the MXCSR FTZ control bit causes
> > outputs to be flushed to zero "when it detects a floating-point
> > underflow condition".  This means that we mustn't flush to zero if
> > the input is such that after rounding it is no longer tiny.
> >
> > At least one of our guest architectures does underflow detection
> > after rounding but flushing of denormals before rounding (MIPS MSA);
>
> Whacky, but yes, I see that in the msa docs.

> BTW, I'm not keen on your "detect_*" names, without "float_" prefix like 
> (almost?)
> everything else.

Do you have a suggestion for better naming? Maybe
 set_float_detect_ftz()
 get_float_detect_ftz()
to match set/get_float_detect_tininess()? Though "detect"
isn't quite the right verb, I feel...

And for the enum

typedef enum __attribute__((__packed__)) {
    float_ftz_after_rounding = 0,
    float_ftz_before_rounding = 1,
} FloatFTZDetection;

?

(the detect_tininess functions work on a 'bool tininess_before_rounding'
field in float_status, but I think I prefer the enum here, since
what we're setting doesn't have an obvious "on/off" that a bool
would be the natural representation for, unlike e.g. flush_to_zero.)

thanks
-- PMM

Reply via email to