This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libm -fno-builtin


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]