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: Mon, 21 Jun 2021 23:39:16 +0000

Thanks for pointing me to vfp_exceptbits_from_host.  I see it setting bit 7 if 
flag_input_denormal is set, but it does not seem to work.   I never see that 
bit set.

As for the specialization, perhaps we don't need it if all architectures are 
the same, but the current code doesn't match any architecture I'm aware of.  I 
gave the example of "sNaN + denorm".   The HW will not set the "input denormal" 
flag, but qemu will.

If you want to see my test code, I can send that.

   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]