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.hender...@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.hender...@linaro.org>
Sent: Monday, June 21, 2021 4:30 PM
To: Michael Morrell <mmorr...@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~
