[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170319145134.GR2082@port70.net>
Date: Sun, 19 Mar 2017 15:51:34 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] aarch64: add single instruction math functions
* David Edelsohn <dje.gcc@...il.com> [2017-03-19 08:55:58 -0400]:
> I thought that the goal of musl was "Minimal machine-specific code".
> Does musl want to start a new arms race?
this is not ideal, but the generic code is not ideal either.
gcc will inline most calls and those will behave differently
compared to the generic code as explained (at least for some
of the rounding functions and fma)
i plan to add FP_FAST_FMA support in math.h but for that
targets with fma should have a single instruction implementation.
(it turns out gcc does not set __FP_FAST_FMA correctly so
the libc has to work harder)
another approach i thought of but did not implement was
math/builtin/foo.c has '.. return __builtin_foo(); ..' and
math/arch/foo.c has '#include "../builtin/foo.c"' ifdefed if the
compiler has support for the builtin and it is known to be not a
call libc. (then the maintenance is minimized on the musl side,
it's on the compiler to get it right, but we need much more
configure check machinery)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
