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
> I've also run this through my usual set of aarch64 RISU tests.
> Thoughts?

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"


Reply via email to