On Wed, Dec 05, 2018 at 06:07:44 -0500, Programmingkid wrote:
>
> > On Dec 4, 2018, at 2:10 PM, qemu-devel-requ...@nongnu.org wrote:
> >
> > Emilio G. Cota writes:
> >
> >> On Tue, Dec 04, 2018 at 13:52:16 +, Alex Benn?e wrote:
> We could always
>
> #ifdef __FAST_MATH__
> >>
> On Dec 4, 2018, at 2:10 PM, qemu-devel-requ...@nongnu.org wrote:
>
> Emilio G. Cota writes:
>
>> On Tue, Dec 04, 2018 at 13:52:16 +, Alex Benn?e wrote:
We could always
#ifdef __FAST_MATH__
#error "Silliness like this will get you nowhere"
#endif
>>>
>>> Emilio,
Emilio G. Cota writes:
> On Tue, Dec 04, 2018 at 13:52:16 +, Alex Bennée wrote:
>> > We could always
>> >
>> > #ifdef __FAST_MATH__
>> > #error "Silliness like this will get you nowhere"
>> > #endif
>>
>> Emilio, are you happy to add that guard with a suitable pithy comment?
>
> Isn't it be
On Tue, Dec 04, 2018 at 13:52:16 +, Alex Bennée wrote:
> > We could always
> >
> > #ifdef __FAST_MATH__
> > #error "Silliness like this will get you nowhere"
> > #endif
>
> Emilio, are you happy to add that guard with a suitable pithy comment?
Isn't it better to just disable hardfloat then?
Richard Henderson writes:
> On 12/4/18 6:28 AM, Alex Bennée wrote:
>> Emilio G. Cota writes:
>>> This assumes that QEMU is running on an IEEE754-compliant FPU and
>>> that the rounding is set to the default (to nearest). The
>>> implementation-dependent specifics of the FPU should not matter;
On 12/4/18 6:28 AM, Alex Bennée wrote:
> Emilio G. Cota writes:
>> This assumes that QEMU is running on an IEEE754-compliant FPU and
>> that the rounding is set to the default (to nearest). The
>> implementation-dependent specifics of the FPU should not matter; things
>> like tininess detection an
Emilio G. Cota writes:
> The appended paves the way for leveraging the host FPU for a subset
> of guest FP operations. For most guest workloads (e.g. FP flags
> aren't ever cleared, inexact occurs often and rounding is set to the
> default [to nearest]) this will yield sizable performance speed
On Sun, Nov 25, 2018 at 01:25:25 +0100, Aleksandar Markovic wrote:
> > Note: some architectures (at least PPC, there might be others) clear
> > the status flags passed to softfloat before most FP operations. This
> > precludes the use of hardfloat, so to avoid introducing a performance
> > regressi
Hi, Emilio.
> Note: some architectures (at least PPC, there might be others) clear
> the status flags passed to softfloat before most FP operations. This
> precludes the use of hardfloat, so to avoid introducing a performance
> regression for those targets, we add a flag to disable hardfloat.
> In
The appended paves the way for leveraging the host FPU for a subset
of guest FP operations. For most guest workloads (e.g. FP flags
aren't ever cleared, inexact occurs often and rounding is set to the
default [to nearest]) this will yield sizable performance speedups.
The approach followed here av
10 matches
Mail list logo
