] softfloat: Introduce float_flag_inorm_denormal
OK, thanks for the update. I also appreciate you looking at the NaN issue.
Michael
-Original Message-
From: Richard Henderson
Sent: Wednesday, July 14, 2021 9:57 AM
To: Michael Morrell ; qemu-devel@nongnu.org
Subject: Re: [PATCH 03/11
OK, thanks for the update. I also appreciate you looking at the NaN issue.
Michael
-Original Message-
From: Richard Henderson
Sent: Wednesday, July 14, 2021 9:57 AM
To: Michael Morrell ; qemu-devel@nongnu.org
Subject: Re: [PATCH 03/11] softfloat: Introduce float_flag_inorm_denormal
On 7/14/21 9:44 AM, Michael Morrell wrote:
Just curious. What's the expected timeline to get these denormal patches in
the tree?
Next development cycle, at minimum. I need to fix the problems vs NaNs that
you identified.
r~
Just curious. What's the expected timeline to get these denormal patches in
the tree?
-Original Message-
From: Richard Henderson
Sent: Saturday, May 29, 2021 8:21 AM
To: Michael Morrell ; qemu-devel@nongnu.org
Cc: alex.ben...@linaro.org
Subject: Re: [PATCH 03/11] softfloat: Introduce
On 6/7/21 10:19 AM, Alex Bennée wrote:
If you've got a better ordering of operations for this, do tell.
What I really want is to know which instructions translate into the if
(s->flush_inputs_to_zero) and verifying that is only checked once. Maybe
I'm just suspicious of compilers ability to
Richard Henderson writes:
> On 6/7/21 8:35 AM, Alex Bennée wrote:
>> So I'm guessing Emilio had the original flush code split was to avoid
>> multiple checks against s->flush_inputs_to_zero in the code. The was
>> possibly a good reason, comparing the before/after of float32_mul:
>
> I assumed
On 6/7/21 8:35 AM, Alex Bennée wrote:
So I'm guessing Emilio had the original flush code split was to avoid
multiple checks against s->flush_inputs_to_zero in the code. The was
possibly a good reason, comparing the before/after of float32_mul:
I assumed that the most important thing now is
Alex Bennée writes:
> Richard Henderson writes:
>
>> Create a new exception flag for reporting input denormals that are not
>> flushed to zero, they are normalized and treated as normal numbers.
>>
>> Signed-off-by: Richard Henderson
>
> Anyway other than that observation seems OK to me:
>
Richard Henderson writes:
> Create a new exception flag for reporting input denormals that are not
> flushed to zero, they are normalized and treated as normal numbers.
>
> Signed-off-by: Richard Henderson
> ---
> include/fpu/softfloat-types.h | 15 ---
> fpu/softfloat.c |
On 5/28/21 10:41 AM, Michael Morrell wrote:
I'm probably missing something, but why do we need both "float_flag_inorm_denormal" and
"float_flag_iflush_denormal"?
Couldn't the code that sets these flags set just a single flag for all denormal
inputs and the code that checks these flags check
I'm probably missing something, but why do we need both
"float_flag_inorm_denormal" and "float_flag_iflush_denormal"?
Couldn't the code that sets these flags set just a single flag for all denormal
inputs and the code that checks these flags check that single flag
combined with the
11 matches
Mail list logo
