[Bug go/94466] New: libgo reflect test compilation very slow on 64-bit SPARC
ro at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Fri Apr 3 10:51:29 GMT 2020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94466
Bug ID: 94466
Summary: libgo reflect test compilation very slow on 64-bit
SPARC
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: ro at gcc dot gnu.org
CC: cmang at google dot com
Target Milestone: ---
Host: sparc*-sun-solaris2.11
Target: sparc*-sun-solaris2.11
Build: sparc*-sun-solaris2.11
I happened to notice that the libgo reflect test takes excessively long on
64-bit SPARC:
32-bit 64-bit
real 4:11.73 15:25.70
user 3:30.87 14:41.32
sys 3.19 3.72
This happens both with a 32-bit-default and 64-bit default compiler.
Looking closer, all the time is spent here:
/var/gcc/regression/master/11.4-gcc/build/./gcc/gccgo
-B/var/gcc/regression/master/11.4-gcc/build/./gcc/
-B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/
-isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem
/vol/gcc/sparc-sun-solaris2.11/sys-include -fchecking=1 -m64 -g -O2 -L
/var/gcc/regression/master/11.4-gcc/build/sparc-sun-solaris2.11/sparcv9/libgo
-L
/var/gcc/regression/master/11.4-gcc/build/sparc-sun-solaris2.11/sparcv9/libgo/.libs
-g -fgo-pkgpath=reflect_test -c -I . -fno-toplevel-reorder -o _xtest_.o
_first_test.go all_test.go example_test.go set_test.go tostring_test.go
Adding -ftime-report reveals
variable tracking : 9.94 ( 1%) 0.14 ( 3%) 9.96 ( 1%)
7944 kB ( 3%)
var-tracking dataflow : 424.42 ( 45%) 0.25 ( 6%) 424.65 ( 45%)
1422 kB ( 1%)
var-tracking emit : 360.20 ( 39%) 0.21 ( 5%) 360.54 ( 38%)
2286 kB ( 1%)
and indeed with -fno-var-tracking-assignments, compilation time goes down to
real 2:20.69
user 2:11.71
sys 2.37
I notice that this is already used in go.test/go-test.exp.
Besides the long compilation time itself, there's another issue: unlike the
DejaGnu testsuite, the timeout (300 s in dg, 240 s in gotest) applies only to
the test execution, not the compilation steps. This was excessively notable
here: I usually run a -j64 bootstrap and some libgo tests are the very last
to run, when everything else has already finished. So this single tests adds
15+ minutes to the whole bootstrap/test time.
Btw., the same problem exists almost identically on the gcc-8 and gcc-9
branches.
More information about the Gcc-bugs
mailing list