Gabriel Dos Reis schrieb:
On Mon, Sep 3, 2012 at 11:29 AM, Georg-Johann Lay <a...@gjlay.de> wrote:
AVR-Libc comes with hand-optimized float support functions written
in assembler. These functions use the same naming conventions like
libgcc. There are situations where this name clashed lead to performance
regression because the functions from libgcc are linked. One example
are the new fixed-point support that convert fixed-point to/from float
and reference float/int conversion functions from within libgcc.
The float implementation in libm.a have been discussed several times
with the only result that it is very unlikely that the code will
ever be integrated into libgcc because the original authors are no
more around. And is is much less work to add a new configure switch
than to port and integrate the code, given there were no license issues.
One point against such an extension was that such change to the compiler
establishes a dependency between the compiler and AVR-Libc, but this
decision has been made long ago by accepting code that actually should
had been added to libgcc -- but was not for whatever reason.
This patch removes that performance regressions by removing the
doubly implemented functions from libgcc by means of a new configure
option --with-avrlibc.
Johann,
as I stated yesterday, I do not understand why there needs to be yet another
configure option. The NATURAL libc for ARV targets is ARV-libc. We
should not need a switch for that.
There is also newlib that is used with avr-gcc. I know this because
some bugs are only triggered for newlib. If there are users that
report bugs if avr-gcc is build for newlib, I'd guess these users are
actually interested in using newlib.
It's clear that the proposed changes do *not* work with newlib
because newlib does not mimic parts of libgcc.
Johann
Moreover, some specs are adjusted so that -lm is treated very much like
-lgcc so that the user need not specify -lm by hand for core float
support like int/float conversions.
Without this patch, LTO compilations also lead to performance regression
because lto adds -plugin-opt=-pass-through=-lgcc etc. prior to the -lm
specified by the user.
Other cases where code is improved are C++ programs, see PR28718 for a
discussion.
There are less fails in gcc.dg/fixed-point, presumably because the rounding
is as expected by the test cases, i.e. there are no rounding errors as
mentioned in the review for PR54222:
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01586.html
Ok to install?
Johann
PR target/54461
* configure.ac (noconfigdirs,target=avr-*-*): Add target-newlib,
target-libgloss if configured --with-avrlibc.
* configure: Regenerate.
libgcc/
PR target/54461
* config.host (tmake_file,host=avr-*-*): Add avr/t-avrlibc if
configured --with-avrlibc.
* config/avr/t-avrlibc: New file.
gcc/
PR target/54461
* config.gcc (tm_file,target=avr-*-*): Add avr/avrlibc.h if
configured --with-avrlibc.
(tm_defines,target=avr-*-*): Add WITH_AVRLIBC if configured
--with-avrlibc.
* config/avr/avrlibc.h: New file.
* config/avr/avr-c.c: Build-in define __WITH_AVRLIBC__ if
configured --with-avrlibc.
