Re: [RFC PATCH 0/4] Idea for using hardfloat in PPC

2022-10-07 Thread Richard Henderson
On 10/7/22 06:42, Alex Bennée wrote: Is ppc unique in not persisting the inexact flag from previous operations? Better phrased as "having an additional per-operation flags for inexact and 'rounded'", because ppc also has the standard ieee sticky inexact flag. But yes, as far as I know ppc

Re: [RFC PATCH 0/4] Idea for using hardfloat in PPC

2022-10-07 Thread Alex Bennée
Richard Henderson writes: > On 10/5/22 07:37, Víctor Colombo wrote: >> However, the impact in performance was not the expected. In x86_64 I >> had a small 3% improvement, while in a Power9 machine there was a small >> performance loss, as can be seem below (100 executions). >> || min

Re: [RFC PATCH 0/4] Idea for using hardfloat in PPC

2022-10-05 Thread Richard Henderson
On 10/5/22 07:37, Víctor Colombo wrote: However, the impact in performance was not the expected. In x86_64 I had a small 3% improvement, while in a Power9 machine there was a small performance loss, as can be seem below (100 executions). || min [s] | max [s] | avg [s] | | before |

[RFC PATCH 0/4] Idea for using hardfloat in PPC

2022-10-05 Thread Víctor Colombo
As can be seem in the mailing thread that added hardfloat support in QEMU [1], a requirement for it to work is to have float_flag_inexact set when entering the API in softfloat.c. However, in the same thread, it was explained that PPC target would not work by default with this implementation. The