https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52357
Dominik Vogt <vogt at linux dot vnet.ibm.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vogt at linux dot vnet.ibm.com
--- Comment #4 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
This also happens intermittently on my s390x development machine (a zEC12) with
the current 5.0 development trunk.
(In reply to Ian Lance Taylor from comment #1)
> Interestingly, the time for cmpldivide.go on SPARC appears to be primarily
> in the register allocator while compiling.
To be specific:
LRA hard reg assignment : 217.88 (95%) usr 0.29 (74%) sys 218.24 (95%)
wall 0 kB ( 0%) ggc
> This is true even though no -O option is used.
Actually, on s390x it does not happen
--
Observation
-----------
Compile time of the test is normally about 4 minutes, but I've seen ~3:50 as
well as ~4:45. When the machine is slow for some reason (probably does not
matter why), compile time may become more than 5 minutes and therefore the test
times out.
Explanation
-----------
The test defines a long array of structures with three complex numbers in
cmplxdivide1.go:
var tests = []Test{
Test{complex(0, 0), complex(0, 0), complex(-nan, -nan)},
Test{complex(0, 0), complex(0, 1), complex(0, 0)},
...
}
The constants like "nan" map to exported symbols of the math package (unlike C
where this would probably be done with macros): "nan" appears in the code as
"math.NaN@plt". With dynamic linkage the actual value is unknown at compile
time, and the structure "tests" is initialised in the init function of the main
package. Compiling with -O0, the executable is about 1.5 MB, and more than 90%
of that is code in the init function. For each line in the table the assembler
instuctions to initialise is consume about 420 bytes.
As far as I was told, the register allocation code has some trouble with huge
basic blocks of simple code like in this case, when the number of possibilities
explodes.
Note: With -O3, the code compiles in less than two seconds, probably because
the code in the init function is reduced drastically before the expensive
register allocation pass.
