[Bug go/94466] New: libgo reflect test compilation very slow on 64-bit SPARC

[ro at gcc dot gnu.org]

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.