This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: libgo patch committed: Copy hash code from Go 1.7 runtime
- From: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>
- To: Ian Lance Taylor <iant at golang dot org>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, "gofrontend-dev\@googlegroups.com" <gofrontend-dev at googlegroups dot com>
- Date: Fri, 09 Dec 2016 10:37:40 +0100
- Subject: Re: libgo patch committed: Copy hash code from Go 1.7 runtime
- Authentication-results: sourceware.org; auth=none
- References: <CAOyqgcUV6N3o9CVjzsQeKeGNKT269R=mktBAV4mTyw-hCW9Eqg@mail.gmail.com>
Hi Ian,
> This patch to libgo copies the memory hashing code from the Go 1.7
> runtime. This is particular important because we earlier copied the
> hashmap code from Go 1.7, and that changed hash table sizes from prime
> numbers to powers of two. The memory hashing code used before this
> patch was fine for prime numbers but for powers of two tended to hash
> many values to the same bucket, making maps much much slower than they
> should be.
>
> I rewrote the AES hashing code from gc assembler to C code using
> intrinsics. The resulting code generates the same hash code for the
> same input as the gc code--that doesn't matter as such, but testing it
> ensures that the C code does something useful.
>
> I changed mips64pe32le to mips64p32le in configure script--noticed
> during CL review.
>
> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu, both with
> and without the AES hashing code. Committed to mainline.
this broke Solaris in two different ways:
* On both sparc and x86, libgo fails to compile:
In file included from /vol/gcc/src/hg/trunk/local/libgo/runtime/runtime.h:114:0,
from /vol/gcc/src/hg/trunk/local/libgo/runtime/aeshash.c:7:
./runtime.inc:8:12: error: expected identifier or '(' before numeric constant
#define m1 3168982561
^
./runtime.inc:782:11: note: in expansion of macro 'm1'
uint32_t m1;
^~
./runtime.inc:9:12: error: expected identifier or '(' before numeric constant
#define m2 3339683297
^
./runtime.inc:783:11: note: in expansion of macro 'm2'
uint32_t m2;
^~
./runtime.inc:10:12: error: expected identifier or '(' before numeric constant
#define m3 832293441
^
./runtime.inc:784:11: note: in expansion of macro 'm3'
uint32_t m3;
^~
./runtime.inc:11:12: error: expected identifier or '(' before numeric constant
#define m4 2336365089
^
./runtime.inc:785:11: note: in expansion of macro 'm4'
uint32_t m4;
^~
This is similar to what we had with c[01] before, and fixed in the
same way:
# HG changeset patch
# Parent b803ae8e678ea6de73d9892aad7b4b33740ae81a
Fix runtime/aeshash.c on Solaris
diff --git a/libgo/Makefile.am b/libgo/Makefile.am
--- a/libgo/Makefile.am
+++ b/libgo/Makefile.am
@@ -561,7 +561,7 @@ s-sigtab: $(srcdir)/mksigtab.sh gen-sysi
runtime.inc: s-runtime-inc; @true
s-runtime-inc: runtime.lo Makefile
rm -f runtime.inc.tmp2
- grep -v "#define _" runtime.inc.tmp | grep -v "#define c[01] " > runtime.inc.tmp2
+ grep -v "#define _" runtime.inc.tmp | grep -v "#define c[01] " | grep -v "#define m[1-4] " > runtime.inc.tmp2
for pattern in '_[GP][a-z]' _Max _Lock _Sig _Trace _MHeap _Num; do \
grep "#define $$pattern" runtime.inc.tmp >> runtime.inc.tmp2; \
done
* Once the build completes, on Solaris/x86 with /bin/as every single Go
execution test FAILs:
ld.so.1: a.out: fatal: /var/gcc/regression/trunk/12-gcc/build/i386-pc-solaris2.12/libgo/.libs/libgo.so.10: hardware capability (CA_SUNW_HW_1) unsupported: 0x4400000 [ AES SSSE3 ]
/vol/gcc/src/hg/trunk/local/libgo/testsuite/gotest[638]: wait: 19831: Killed
/vol/gcc/src/hg/trunk/local/libgo/testsuite/gotest[643]: wait: 19832: Terminated
/bin/ksh: 9035: Killed
FAIL: bufio
ld.so.1: array-1.x: fatal: /var/gcc/regression/trunk/12-gcc/build/i386-pc-solaris2.12/./libgo/.libs/libgo.so.10: hardware capability (CA_SUNW_HW_1) unsupported: 0x4400000 [ AES SSSE3 ]
FAIL: go.go-torture/execute/array-1.go execution, -O0
Again, this is a known issue, previously in libitm and recently in
libgfortran. The latter is fixed by my (still unreviewed) patch
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00336.html
and can be fixed for libgo along the same lines (on top of the
libgfortran etc. one):
2016-12-09 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
* configure.ac: Call GCC_CHECK_LINKER_HWCAP.
* Makefile.am (AM_LDFLAGS): Initialize to HWCAP_LDFLAGS.
[USING_SPLIT_STACK]: Add to AM_LDFLAGS.
* aclocal.m4: Regenerate.
* configure: Regenerate.
* Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.
# HG changeset patch
# Parent b803ae8e678ea6de73d9892aad7b4b33740ae81a
Disable hwcaps on libgo
diff --git a/libgo/Makefile.am b/libgo/Makefile.am
--- a/libgo/Makefile.am
+++ b/libgo/Makefile.am
@@ -46,8 +46,10 @@ AM_CFLAGS = -fexceptions -fnon-call-exce
-I $(srcdir)/../libgcc -I $(srcdir)/../libbacktrace \
-I $(MULTIBUILDTOP)../../gcc/include
+AM_LDFLAGS = $(HWCAP_LDFLAGS)
+
if USING_SPLIT_STACK
-AM_LDFLAGS = -XCClinker $(SPLIT_STACK)
+AM_LDFLAGS += -XCClinker $(SPLIT_STACK)
endif
# Multilib support.
diff --git a/libgo/configure.ac b/libgo/configure.ac
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -430,6 +430,9 @@ case "$target" in
esac
AC_SUBST(OSLDFLAGS)
+dnl Check linker hardware capability support.
+GCC_CHECK_LINKER_HWCAP
+
dnl Use -fsplit-stack when compiling C code if available.
AC_CACHE_CHECK([whether -fsplit-stack is supported],
[libgo_cv_c_split_stack_supported],
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University