This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: libm -fno-builtin
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: "jon at beniston dot com" <jon at beniston dot com>
- Cc: nd <nd at arm dot com>, "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Fri, 24 Aug 2018 14:52:15 +0000
- Subject: Re: libm -fno-builtin
- References: <DB5PR08MB1030126631B8F7A73D2DE2B0833D0@DB5PR08MB1030.eurprd08.prod.outlook.com> <294c01d4365f$6bc14bd0$4343e370$@beniston.com>,<2a6a01d43660$dd91b0a0$98b511e0$@beniston.com>
jon@beniston.com wrote:
>Using -fno-builtin-memcpy doesn't prevent GCC from replacing a loop
>with a call to memcpy (likewise for memset). As Joesph said before,
>-fno-tree-loop-distribute-patterns should be used for that. However,
>this probably it isn't needed, as this only gets enabled at -O3 anyway,
>and Newlib compiles with O2.
>
>Note that -fno-builtin does prevent this, oddly, but obviously
>we don't want to use that.
That looks like a bug indeed since nobody will remember to use
-fno-tree-loop-distribute-patterns.
However it is quite feasible to use -fno-builtin as an extra option on a few
files if they need it. Newlib might not need it today, but GLIBC has a few uses.
>Perhaps GCC should be a little bit more clever, and not try to use this
>optimisation if the function called matches the name of the function being
compiled.
That would be even better. However that doesn't work in all cases, for
example GLIBC often uses different names to avoid namespace issues.
Wilco