This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Improving math function wrappers
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>, Joseph Myers <joseph at codesourcery dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Cc: nd <nd at arm dot com>
- Date: Thu, 16 Mar 2017 13:52:55 +0000
- Subject: Improving math function wrappers
- Authentication-results: sourceware.org; auth=none
- Authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=arm.com;
- Nodisclaimer: True
- References: <AM5PR0802MB2610AA7EDC518B39F6D7152683260@AM5PR0802MB2610.eurprd08.prod.outlook.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
Hi,
When looking at profiles of various benchmarks that use math functions, I noticed
that the wrappers that set errno have a significant overhead. This is particularly
noticeable when the wrapper tests the return value of the math function - this requires
the input operand(s) to be saved, creating a stack frame and several callee-saves.
While the wrappers may be bypassed when building with -Ofast, this uses C header
magic (ie. it doesn't work in languages other than C and C++). Given other languages
don't even have the concept of errno, C99 doesn't require it, and no application ever
reads errno, it is inefficient to force the use of the wrappers in almost all cases.
One way of improving this would be to reverse the current logic and default to the
unwrapped IEEE functions. The errno wrapper would then only be selected when the
standard requires it (C89), on old (obsolete?) UNIX variants that assume errno is
always set, or if the user explicitly requests it.
Another possibility would be to merge the wrappers into their respective math functions.
This is feasible since the IEEE versions must check for the same exceptional cases
anyway. While this would increase complexity of math functions, it shouldn't affect the
critical path for the common cases. However it would mean errno is sometimes set
when it otherwise wouldn't be (with Ofast or when an IEEE math function is called
internally). Also on some odd systems it might even result in extra messages being
printed by __kernel_standard (can we obsolete that???).
What do you think?
Wilco