From: Joseph Myers <joseph@codesourcery.com>
To: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Cc: "libc-alpha@sourceware.org" <libc-alpha@sourceware.org>, nd <nd@arm.com>
Subject: Re: [PATCH v3 1/3] Cleanup __ieee754_sqrt(f/l)
Date: Wed, 14 Mar 2018 16:50:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.20.1803141643210.26962@digraph.polyomino.org.uk> (raw)
In-Reply-To: <DB6PR0801MB2053D6F27EA932320705462B83D10@DB6PR0801MB2053.eurprd08.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 2835 bytes --]
On Wed, 14 Mar 2018, Wilco Dijkstra wrote:
> Maybe we can agree on a useful subset in the script - the number of
> variants for some ISAs is ridiculous, do we really need 24 variants for
> MIPS? I suppose we can also remove tile and a few others like sh given
> the recent discussions of obsoleting those ports?
The point is to cover all ABIs supported by glibc (of which there are 24
for MIPS), and then useful non-ABI variants that significantly affect the
code that gets built.
If an architecture port is removed from glibc, the same commit removing it
from glibc should of course remove it from build-many-glibcs.py. If tile
does get removed from the Linux kernel I think at that point we should
remove it from glibc. I'm not aware of any evidence that sh is going to
be removed from the Linux kernel or any proposals to remove it from glibc
(although it does need a maintainer in glibc).
> > What execution testing have you done? It would be a good idea for that to
> > include at least one configuration where sqrt is not inlined by the
> > compiler, and also to include 32-bit x86 to make sure the special-case
> > wrappers there (to avoid double rounding) continue to work as expected.
>
> I run on AArch64 and x64 when it is relevant. Finding a config that
> doesn't inline sqrt may be difficult, since pretty much all ISAs have a
> sqrt instruction.
Soft-float configurations (e.g. soft-float ARM) don't inline sqrt.
> We build the testsuite explicitly with -fmath-errno so there will be
> calls to sqrt. Given the include path is incorrect when running the
> testsuite (it uses internal paths rather than external ones), we get
_ISOMAC should be defined for building the testsuite except for a few
tests listed in tests-internal. The include/ headers should, when _ISOMAC
is defined, do nothing except include the corresponding public header
(which is required so it gets found at all, since directories such as
math/ contain the public headers but aren't in the include search path
when building source files from other glibc subdirectories).
> redirection to __ieee754_sqrt which is not exported outside of GLIBC.
> Since the include path issue is a separate bug I just ensure the sqrt
> benchmark gets the right include - when it is fixed we can easily change
> it back.
If the benchmarks are compiled without _ISOMAC being defined, that's the
bug that should be fixed. Changing them to use math/math.h is definitely
wrong.
> Btw we'll also need to create some real inputs and decide what we want
> to test: the inlined sqrt instruction or the sqrt call in GLIBC (which
> will usually be the sqrt instruction), or the sqrt emulation...
The benchmarks are supposed to test the function call in glibc (and thus
use -fno-builtin).
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2018-03-14 16:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-13 18:27 Wilco Dijkstra
2018-03-13 22:46 ` Joseph Myers
2018-03-14 14:47 ` Wilco Dijkstra
2018-03-14 16:50 ` Joseph Myers [this message]
2018-03-14 17:34 ` Wilco Dijkstra
2018-03-14 17:44 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1803141643210.26962@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=Wilco.Dijkstra@arm.com \
--cc=libc-alpha@sourceware.org \
--cc=nd@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).