| Message ID | mcraa4tt8sx.fsf@dhcp-172-18-216-180.mtv.corp.google.com |
|---|---|
| State | New |
| Headers | show |
On Wed, Feb 8, 2012 at 8:38 PM, Ian Lance Taylor <iant@google.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. Richard. > 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. > > Ian >
Richard Guenther <richard.guenther@gmail.com> writes: > On Wed, Feb 8, 2012 at 8:38 PM, Ian Lance Taylor <iant@google.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. Yes, that approach would make sense, but this doesn't seem like the right time to do it. The -funsafe-math-optimizations option does not permit arbitrary behaviour. It merely permits a set of optimizations which violate strict IEEE conformance. I believe the Go math library can be safe in the presence of those optimizations, because the library does explicit checks for NaN and infinity, where necessary, before it does the actual operation. The math library has a fairly extensive set of tests, including tests of exceptional conditions, and it passes the tests when using -funsafe-math-optimizations. Note that I'm only using -funsafe-math-optimizations on x86. Ian
On Thu, Feb 9, 2012 at 6:32 PM, Ian Lance Taylor <iant@google.com> wrote: > Richard Guenther <richard.guenther@gmail.com> writes: > >> On Wed, Feb 8, 2012 at 8:38 PM, Ian Lance Taylor <iant@google.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. > > Yes, that approach would make sense, but this doesn't seem like the > right time to do it. > > The -funsafe-math-optimizations option does not permit arbitrary > behaviour. It merely permits a set of optimizations which violate > strict IEEE conformance. I believe the Go math library can be safe in > the presence of those optimizations, because the library does explicit > checks for NaN and infinity, where necessary, before it does the actual > operation. The math library has a fairly extensive set of tests, > including tests of exceptional conditions, and it passes the tests when > using -funsafe-math-optimizations. Note that I'm only using > -funsafe-math-optimizations on x86. I see. -funsafe-math-optimizations affects precision though (it doesn't assume NaNs or Infinities do not happen), see the docs - it enables -fno-signed-zeros, -fno-trapping-math, -fassociative-math and -freciprocal-math. Richard. > Ian
Richard Guenther <richard.guenther@gmail.com> writes: > On Thu, Feb 9, 2012 at 6:32 PM, Ian Lance Taylor <iant@google.com> wrote: >> Richard Guenther <richard.guenther@gmail.com> writes: >> >>> On Wed, Feb 8, 2012 at 8:38 PM, Ian Lance Taylor <iant@google.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. >> >> Yes, that approach would make sense, but this doesn't seem like the >> right time to do it. >> >> The -funsafe-math-optimizations option does not permit arbitrary >> behaviour. It merely permits a set of optimizations which violate >> strict IEEE conformance. I believe the Go math library can be safe in >> the presence of those optimizations, because the library does explicit >> checks for NaN and infinity, where necessary, before it does the actual >> operation. The math library has a fairly extensive set of tests, >> including tests of exceptional conditions, and it passes the tests when >> using -funsafe-math-optimizations. Note that I'm only using >> -funsafe-math-optimizations on x86. > > I see. -funsafe-math-optimizations affects precision though (it doesn't > assume NaNs or Infinities do not happen), see the docs - it enables > -fno-signed-zeros, -fno-trapping-math, -fassociative-math and -freciprocal-math. Affecting precision is OK for the Go math library, since the master version of the library is written to use the 80-bit 80387 registers on 386, in order to use the magic 80387 instructions. Ian
diff -r 69a7e6220af1 go/expressions.cc --- a/go/expressions.cc Tue Feb 07 22:16:02 2012 -0800 +++ b/go/expressions.cc Wed Feb 08 11:29:04 2012 -0800 @@ -10027,7 +10027,8 @@ // This is to support builtin math functions when using 80387 math. tree excess_type = NULL_TREE; - if (TREE_CODE(fndecl) == FUNCTION_DECL + if (optimize + && TREE_CODE(fndecl) == FUNCTION_DECL && DECL_IS_BUILTIN(fndecl) && DECL_BUILT_IN_CLASS(fndecl) == BUILT_IN_NORMAL && nargs > 0 diff -r 69a7e6220af1 libgo/Makefile.am --- a/libgo/Makefile.am Tue Feb 07 22:16:02 2012 -0800 +++ b/libgo/Makefile.am Wed Feb 08 11:29:04 2012 -0800 @@ -1959,7 +1959,9 @@ math/math.lo.dep: $(go_math_files) $(BUILDDEPS) math/math.lo: $(go_math_files) - $(BUILDPACKAGE) + $(MKDIR_P) $(@D) + files=`echo $^ | sed -e 's/[^ ]*\.gox//g'`; \ + $(LTGOCOMPILE) $(MATH_FLAG) -I . -c -fgo-prefix="libgo_$(@D)" -o $@ $$files math/check: $(CHECK_DEPS) @$(CHECK) .PHONY: math/check diff -r 69a7e6220af1 libgo/configure.ac --- a/libgo/configure.ac Tue Feb 07 22:16:02 2012 -0800 +++ b/libgo/configure.ac Wed Feb 08 11:29:04 2012 -0800 @@ -522,6 +522,23 @@ fi AC_SUBST(STRINGOPS_FLAG) +dnl For x86 we want to compile the math library with -mfancy-math-387 +dnl -funsafe-math-optimizations so that we can use the builtin +dnl instructions directly. +AC_CACHE_CHECK([whether compiler supports -mfancy-math-387], +[libgo_cv_c_fancymath], +[CFLAGS_hold=$CFLAGS +CFLAGS="$CFLAGS -mfancy-math-387" +AC_COMPILE_IFELSE([int i;], +[libgo_cv_c_fancymath=yes], +[libgo_cv_c_fancymath=no]) +CFLAGS=$CFLAGS_hold]) +MATH_FLAG= +if test "$libgo_cv_c_fancymath" = yes; then + MATH_FLAG="-mfancy-math-387 -funsafe-math-optimizations" +fi +AC_SUBST(MATH_FLAG) + CFLAGS_hold=$CFLAGS CFLAGS="$CFLAGS -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE" AC_CHECK_TYPES([off64_t])