On Sun, Feb 4, 2018 at 5:11 AM, Richard Henderson
> 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.
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:
"endianness not defined by sfp-machine.h"
# error "endianness not defined by sfp-machine.h"