qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Denormal input handling


From: Michael Morrell
Subject: RE: Denormal input handling
Date: Tue, 22 Jun 2021 18:50:26 +0000

OK, I've done more testing.  I'm not sure if we need any specialization, but 
the setting for float_flag_inorm_denormal isn't right for x86.

It is set unconditionally when flush_inputs_to_zero is false, but it needs to 
take into account the other operand(s).   Given "denorm / 0" or any instruction 
with a NaN operand, float_flag_inorm_denormal should not be set (and that way, 
the DE bit in MXCSR won't be set when it shouldn't be).

   Michael

-----Original Message-----
From: Michael Morrell 
Sent: Monday, June 21, 2021 5:57 PM
To: 'Richard Henderson' <richard.henderson@linaro.org>; qemu-devel@nongnu.org
Subject: RE: Denormal input handling

Richard,

I was under the mistaken impression that your changes in this area (splitting 
float_flag_input_denormal into 2 flags) were already checked in, but I see now 
that is not the case.  I should probably wait until that is done before I try 
to claim there are additional issues here.

    Michael

-----Original Message-----
From: Richard Henderson <richard.henderson@linaro.org>
Sent: Monday, June 21, 2021 4:30 PM
To: Michael Morrell <mmorrell@tachyum.com>; qemu-devel@nongnu.org
Subject: Re: Denormal input handling

On 6/21/21 4:13 PM, Michael Morrell wrote:
> I have another couple of thoughts around input denormal handling.
> 
> The first is straightforward.  I noticed that the Aarch64 port doesn't 
> report input denormals (I could not find any code which sets the IDC 
> bit in the FPSR).  I found code in the arm (not aarch64) port that 
> sets other bits like IXC, but nothing for IDC.   Is that simply because no 
> one has bothered to add this support?

It's because we failed to use symbolic constants.  See 
vfp_exceptbits_from_host.  Which
*is* used for both aarch64 and arm.


> The second concerns support for cases where multiple exception 
> conditions occur.   I had originally thought that denormal input 
> handling would be orthogonal to everything else and so a case like 
> "sNaN  + denorm" would set both the invalid and input denormal flags 
> or "denorm / 0" would set both idivde by zero and input denormal, but I don't 
> think that is true for at least some architectures.  Perhaps some 
> specialization is needed here?

If you've got a specific example, we can look at it.  There's no point adding 
specialization that isn't going to be used.


r~

reply via email to

[Prev in Thread] Current Thread [Next in Thread]