On Sun, Feb 4, 2018 at 5:11 AM, Richard Henderson <richard.hender...@linaro.org> wrote: > As discussed on list, the structure and inline function solution that > Alex and I have been writing from scratch introduces a sizeable > performance regression. Alex and I have done some work earlier > in the week that improved things some, but not enough. > > Which leaves us with a bit of a problem. The were two existing > code bases that we originally considered: > > There's softfloat v3, which would need a large structural reorg in > order to be able to handle multiple float_status contexts. But when > Alex communicated with upstream they weren't ready to accept patches. > > Or there's the code from glibc. I know Peter didn't like the idea; > debugging this code is fairly painful -- the massive preprocessor > macros mean that you can't step through anything. But at least we > have a good relationship with glibc, so merging patches back and > forth should be easy. > > The result seems to perform slightly better than mainline. > With an aarch64 guest and a i7-8550U host, nbench gives > > - FLOATING-POINT INDEX: 3.095 > + FLOATING-POINT INDEX: 3.438 > > I've also run this through my usual set of aarch64 RISU tests. > > Thoughts? > > Hi,
Thanks for looking into this. It seems this code does not build on OSX Sierra nor while cross compiling for Windows on Fedora 27: In file included from /Users/hsp/src/qemu-softfloatglibc/fpu/float16.c:20: /Users/hsp/src/qemu-softfloatglibc/fpu/soft-fp.h:50:4: error: "endianness not defined by sfp-machine.h" # error "endianness not defined by sfp-machine.h" Best, Howard
