Re: Denormal input handling

[Michael Morrell via <qemu-devel@nongnu.org>]

[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]

 Richard,

How is what I suggested wrong for x86? It matches the spec and actual behavior:

== Start quote ==
10.2.3.4 Denormals-Are-Zeros

Bit 6 (DAZ) of the MXCSR register enables the denormals-are-zeros mode, which controls the processor’s response 
to a SIMD floating-point denormal operand condition. When the denormals-are-zeros flag is set, the processor 
converts all denormal source operands to a zero with the sign of the original operand before performing any 
computations on them. The processor does not set the denormal-operand exception flag (DE), regardless of the 
setting of the denormal-operand exception mask bit (DM); and it does not generate a denormal-operand exception 
if the exception is unmasked.
== End quote ==

So, DE should not be set for a denormal input if DAZ is set (it is set only when DAZ is 0 -- the default "IEEE mode").

Can you point me to the ARM documentation?

 Michael
     On Wednesday, May 26, 2021, 12:28:38 PM PDT, Richard Henderson <richard.henderson@linaro.org> wrote:  
 
 On 5/26/21 12:23 PM, Richard Henderson wrote:
> On 5/26/21 12:02 PM, Michael Morrell via wrote:
>> I think the behavior should be for denormal inputs that if 
>> "flush_inputs_to_zero" is true, then set the value to zero (without setting 
>> the "input denormal" flag); and if "flush_inputs_to_zero" is false, set the 
>> "input denormal" flag and normalize the input.
>>
>> This matches what x86 does (I'm not sure about other architectures).
> 
> It is not.
> 
> Intel Architectures SDM Vol 1, Section 11.5.2.2:
>    The denormal operand exception is not affected by
>    flush-to-zero mode.

Ho hum, I misread what you wrote outside the quoted context.

Both your suggestion and the current behaviour are wrong for x86.  The current 
behavior is correct for arm.

What we need are two separate softfloat flags, one for "any denormal seen on 
input" and another for "denormal flushed to zero on input".

The target emulation code then chooses what set of bits needs exporting to 
target architecture state.


r~
  

[-- Attachment #2: Type: text/html, Size: 3198 bytes --]