This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: libm -fno-builtin
- From: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- To: Jon Beniston <jon at beniston dot com>, newlib at sourceware dot org
- Date: Mon, 25 Jun 2018 17:53:26 +0100
- Subject: Re: libm -fno-builtin
- References: <005301d407c1$b3a9a8b0$1afcfa10$@beniston.com>
On 19/06/18 12:36, Jon Beniston wrote:
> Hi,
>
>
>
> libm is currently built with -fno-builtin. This results in sub-optimal code
> for uses of functions such as fabs & floor. Without -fno-builtin, gcc can
> inline these to single instructions on many targets. As is, we end up with
> function calls, to slower generic code.
>
>
>
> Can -fno-builtin therefore be removed? If there are specific builtins that
> need to be prevented from being used, these can prevented with
> -fno-builtin-function, perhaps even on a per file basis rather than
> globally.
>
>
>
> Are there any known traps before I give it a try?
>
>
>
> Cheers,
>
> Jon
>
>
>
I think use of -fno-builtin when building the C libraries comes from
paranoia as much as anything, but the general problem is that unless you
know exactly how every version of every C compiler will recognize
particular idioms and handle those cases explicitly, you'll occasionally
end up with cyclic definitions.
The canonical example is something like memset. memset idioms are
generally quite easy for the compiler to recognize and I've frequently
seen bug reports from naive users who write
void *
memset (void *p, size_t l)
{
....
}
and then end up with
memset:
jmp memset
because the compiler knows that the body of the function is just, well,
memset!
It gets harder when one function can be implemented in terms of another
with a different name; now you have to know which idioms the compiler
might try to rewrite.
R.