This is the mail archive of the
mailing list for the GCC project.
Re: Go patch committed: Build math library with -funsafe-math-optimizations
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: gcc-patches at gcc dot gnu dot org, gofrontend-dev at googlegroups dot com
- Date: Thu, 9 Feb 2012 11:27:41 +0100
- Subject: Re: Go patch committed: Build math library with -funsafe-math-optimizations
- References: <firstname.lastname@example.org>
On Wed, Feb 8, 2012 at 8:38 PM, Ian Lance Taylor <email@example.com> wrote:
> The master Go math library uses assembler code on 386 processors to take
> advantage of 387 instructions. ?This patch lets gccgo do the same thing,
> by compiling the math library with -funsafe-math-optimizations. ?I also
> pass -mfancy-math-387, although that is the default. ?It would not be
> appropriate to compile all Go code with -funsafe-math-optimizations, of
> course, but the math library is designed to handle it.
Huh ... I'd rather not do that if I were you. Instead I'd say we lack a
machine specific flag to enable the fancy-x87-math patterns which
then -funsafe-math-optimizations should enable. The x87 math
routines are the only thing you are after, right? No math-library
can be _safe_ against -funsafe-math-optimizations I believe.
> The compiler currently rewrites calls to, e.g., acos to call acosl
> instead when using excess precision. ?This also enables the use of
> assembler routines on 387. ?I tweaked the compiler to only do this when
> optimizing, which is probably how it should have been done anyhow. ?(At
> some point this code will move into the gcc interface out of the
> frontend proper.)
> With this change the math library no longer refers to functions like
> acosl on 386 systems--the operations are done inline using 387
> instructions--which should address some portability problems.
> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu (32-bit
> and 64-bit mode). ?Committed to mainline.