mirror of git://sourceware.org/git/glibc.git
This patch adds the narrowing square root functions from TS 18661-1 / TS 18661-3 / C2X to glibc's libm: fsqrt, fsqrtl, dsqrtl, f32sqrtf64, f32sqrtf32x, f32xsqrtf64 for all configurations; f32sqrtf64x, f32sqrtf128, f64sqrtf64x, f64sqrtf128, f32xsqrtf64x, f32xsqrtf128, f64xsqrtf128 for configurations with _Float64x and _Float128; __f32sqrtieee128 and __f64sqrtieee128 aliases in the powerpc64le case (for calls to fsqrtl and dsqrtl when long double is IEEE binary128). Corresponding tgmath.h macro support is also added. The changes are mostly similar to those for the other narrowing functions previously added, so the description of those generally applies to this patch as well. However, the not-actually-narrowing cases (where the two types involved in the function have the same floating-point format) are aliased to sqrt, sqrtl or sqrtf128 rather than needing a separately built not-actually-narrowing function such as was needed for add / sub / mul / div. Thus, there is no __nldbl_dsqrtl name for ldbl-opt because no such name was needed (whereas the other functions needed such a name since the only other name for that entry point was e.g. f32xaddf64, not reserved by TS 18661-1); the headers are made to arrange for sqrt to be called in that case instead. The DIAG_* calls in sysdeps/ieee754/soft-fp/s_dsqrtl.c are because they were observed to be needed in GCC 7 testing of riscv32-linux-gnu-rv32imac-ilp32. The other sysdeps/ieee754/soft-fp/ files added didn't need such DIAG_* in any configuration I tested with build-many-glibcs.py, but if they do turn out to be needed in more files with some other configuration / GCC version, they can always be added there. I reused the same test inputs in auto-libm-test-in as for non-narrowing sqrt rather than adding extra or separate inputs for narrowing sqrt. The tests in libm-test-narrow-sqrt.inc also follow those for non-narrowing sqrt. Tested as followed: natively with the full glibc testsuite for x86_64 (GCC 11, 7, 6) and x86 (GCC 11); with build-many-glibcs.py with GCC 11, 7 and 6; cross testing of math/ tests for powerpc64le, powerpc32 hard float, mips64 (all three ABIs, both hard and soft float). The different GCC versions are to cover the different cases in tgmath.h and tgmath.h tests properly (GCC 6 has _Float* only as typedefs in glibc headers, GCC 7 has proper _Float* support, GCC 8 adds __builtin_tgmath). |
||
|---|---|---|
| .. | ||
| examples | ||
| Makefile | ||
| README.pretty-printers | ||
| README.tunables | ||
| argp.texi | ||
| arith.texi | ||
| charset.texi | ||
| check-safety.sh | ||
| conf.texi | ||
| contrib.texi | ||
| creature.texi | ||
| crypt.texi | ||
| ctype.texi | ||
| debug.texi | ||
| dir | ||
| errno.texi | ||
| fdl-1.3.texi | ||
| filesys.texi | ||
| freemanuals.texi | ||
| getopt.texi | ||
| header.texi | ||
| install-plain.texi | ||
| install.texi | ||
| intro.texi | ||
| io.texi | ||
| ipc.texi | ||
| job.texi | ||
| lang.texi | ||
| lgpl-2.1.texi | ||
| libc-texinfo.sh | ||
| libc.texinfo | ||
| libcbook.texi | ||
| libdl.texi | ||
| llio.texi | ||
| locale.texi | ||
| macros.texi | ||
| maint.texi | ||
| math.texi | ||
| memory.texi | ||
| message.texi | ||
| nss.texi | ||
| nsswitch.texi | ||
| pattern.texi | ||
| pipe.texi | ||
| platform.texi | ||
| probes.texi | ||
| process.texi | ||
| resource.texi | ||
| search.texi | ||
| setjmp.texi | ||
| signal.texi | ||
| socket.texi | ||
| startup.texi | ||
| stdio-fp.c | ||
| stdio.texi | ||
| string.texi | ||
| summary.pl | ||
| sysinfo.texi | ||
| syslog.texi | ||
| terminal.texi | ||
| texinfo.tex | ||
| texis.awk | ||
| threads.texi | ||
| time.texi | ||
| tsort.awk | ||
| tunables.texi | ||
| users.texi | ||
| xtract-typefun.awk | ||
README.tunables
TUNABLE FRAMEWORK
=================
Tunables is a feature in the GNU C Library that allows application authors and
distribution maintainers to alter the runtime library behaviour to match their
workload.
The tunable framework allows modules within glibc to register variables that
may be tweaked through an environment variable. It aims to enforce a strict
namespace rule to bring consistency to naming of these tunable environment
variables across the project. This document is a guide for glibc developers to
add tunables to the framework.
ADDING A NEW TUNABLE
--------------------
The TOP_NAMESPACE macro is defined by default as 'glibc'. If distributions
intend to add their own tunables, they should do so in a different top
namespace by overriding the TOP_NAMESPACE macro for that tunable. Downstream
implementations are discouraged from using the 'glibc' top namespace for
tunables they don't already have consensus to push upstream.
There are three steps to adding a tunable:
1. Add a tunable to the list and fully specify its properties:
For each tunable you want to add, make an entry in elf/dl-tunables.list. The
format of the file is as follows:
TOP_NAMESPACE {
NAMESPACE1 {
TUNABLE1 {
# tunable attributes, one per line
}
# A tunable with default attributes, i.e. string variable.
TUNABLE2
TUNABLE3 {
# its attributes
}
}
NAMESPACE2 {
...
}
}
The list of allowed attributes are:
- type: Data type. Defaults to STRING. Allowed types are:
INT_32, UINT_64, SIZE_T and STRING. Numeric types may
be in octal or hexadecimal format too.
- minval: Optional minimum acceptable value. For a string type
this is the minimum length of the value.
- maxval: Optional maximum acceptable value. For a string type
this is the maximum length of the value.
- default: Specify an optional default value for the tunable.
- env_alias: An alias environment variable
- security_level: Specify security level of the tunable for AT_SECURE
binaries. Valid values are:
SXID_ERASE: (default) Do not read and do not pass on to
child processes.
SXID_IGNORE: Do not read, but retain for non-AT_SECURE
child processes.
NONE: Read all the time.
2. Use TUNABLE_GET/TUNABLE_SET/TUNABLE_SET_WITH_BOUNDS to get and set tunables.
3. OPTIONAL: If tunables in a namespace are being used multiple times within a
specific module, set the TUNABLE_NAMESPACE macro to reduce the amount of
typing.
GETTING AND SETTING TUNABLES
----------------------------
When the TUNABLE_NAMESPACE macro is defined, one may get tunables in that
module using the TUNABLE_GET macro as follows:
val = TUNABLE_GET (check, int32_t, TUNABLE_CALLBACK (check_callback))
where 'check' is the tunable name, 'int32_t' is the C type of the tunable and
'check_callback' is the function to call if the tunable got initialized to a
non-default value. The macro returns the value as type 'int32_t'.
The callback function should be defined as follows:
void
TUNABLE_CALLBACK (check_callback) (int32_t *valp)
{
...
}
where it can expect the tunable value to be passed in VALP.
Tunables in the module can be updated using:
TUNABLE_SET (check, val)
where 'check' is the tunable name and 'val' is a value of same type.
To get and set tunables in a different namespace from that module, use the full
form of the macros as follows:
val = TUNABLE_GET_FULL (glibc, cpu, hwcap_mask, uint64_t, NULL)
TUNABLE_SET_FULL (glibc, cpu, hwcap_mask, val)
where 'glibc' is the top namespace, 'cpu' is the tunable namespace and the
remaining arguments are the same as the short form macros.
The minimum and maximum values can updated together with the tunable value
using:
TUNABLE_SET_WITH_BOUNDS (check, val, min, max)
where 'check' is the tunable name, 'val' is a value of same type, 'min' and
'max' are the minimum and maximum values of the tunable.
To set the minimum and maximum values of tunables in a different namespace
from that module, use the full form of the macros as follows:
val = TUNABLE_GET_FULL (glibc, cpu, hwcap_mask, uint64_t, NULL)
TUNABLE_SET_WITH_BOUNDS_FULL (glibc, cpu, hwcap_mask, val, min, max)
where 'glibc' is the top namespace, 'cpu' is the tunable namespace and the
remaining arguments are the same as the short form macros.
When TUNABLE_NAMESPACE is not defined in a module, TUNABLE_GET is equivalent to
TUNABLE_GET_FULL, so you will need to provide full namespace information for
both macros. Likewise for TUNABLE_SET, TUNABLE_SET_FULL,
TUNABLE_SET_WITH_BOUNDS and TUNABLE_SET_WITH_BOUNDS_FULL.
** IMPORTANT NOTE **
The tunable list is set as read-only after the dynamic linker relocates itself,
so setting tunable values must be limited only to tunables within the dynamic
linker, that too before relocation.
FUTURE WORK
-----------
The framework currently only allows a one-time initialization of variables
through environment variables and in some cases, modification of variables via
an API call. A future goals for this project include:
- Setting system-wide and user-wide defaults for tunables through some
mechanism like a configuration file.
- Allow tweaking of some tunables at runtime