For r221618, this test took 34633750695 "basic clock cycles" in the CRIS simulator. For r222742 (aka. "now"), it takes 40111446541 (same unit). This is a performance regression of about 16% in less than 1.5 month! I noticed because the test started to fail on my autotester machine during times of load, when it has been previously silent. The cris-elf is a 32-bit soft-float target. Note that the situation is the opposite of that in PR65093. I'm listing the libstdc++ component as the cause, will update as my (low-intensity) investigation (which I guess will be mostly bisecting) continues. It is also a likely culprit, with the recent work alluded to in PR65093 (either further work or another side of the coin, of changes there improving performance). My first reaction, before checking for regression, was the test can and should be split up as in PR65093. I still think it should, after the regression is fixed. (Revision r221618 happens to be the last regression-free revision for cris-elf; after that no components outside the gcc repo have been updated.) Relative performance numbers for other platforms at svn revisions near those above would be interesting.
At r222180: 40068917595
Bisecting shows that revision r221859 is the culprit, adding Honza to CC. I hope to add analysis of the compiled code showing (an example of) the regressed code, but it would be really nice if Someone could performance-regression test r221859 (compared to r221858) on another target. Weird that a performance-regression of 16% is supposed to be *fixed* by that commit (see PR65076). While it refers to *compile-time* regression, that is just another name for a *run-time* performance-regression of the bootstrapped compiler, apparently typical for at least the execution-path when compiling tramp3d-v4.cpp supposedly for x86_64-linux and 26_numerics/random/negative_binomial_distribution/operators/values.cc for cris-elf. Note that the regression is not fixed for cris-elf at r222305 (a later additional commit referencing PR65076). Revision-numbers and cycle numbers while bisecting follows. Note the very stable numbers: r221618 34633750695 r221758 34633750695 r221828 34633750695 r221845 34633750695 r221854 34633750695 r221858 34633750695 r221859 40068917595 r221860 40068917595 r221863 40068917595 r221899 40068917595 r222180 40068917595 r222742 40111446541
Something supposedly very good happened recently, because: r223225 18369501023 I'll just have to find out what caused that 50% cut! The test-case is unchanged. If the cause is related to inlining heuristics, I'll close this PR for sure.
(In reply to Hans-Peter Nilsson from comment #3) > Something supposedly very good happened recently, because: > r223225 18369501023 > > I'll just have to find out what caused that 50% cut! The test-case is > unchanged. > If the cause is related to inlining heuristics, I'll close this PR for sure. Ignore that. I misobserved the "nearby" test-case 26_numerics/random/poisson_distribution/operators/values.cc probably because there was a test-run still in progress. Still, that similar test-case indeed seems to have lower initialization numbers. Lesson learned: always double-check your end-point observations before bisecting.
Things got from bad to worse: r225090 40333375286
HP, I think I need bit more analysis here. Do you know what inline decision actually causes the trouble?
(In reply to Jan Hubicka from comment #6) > HP, I think I need bit more analysis here. Do you know what inline decision > actually causes the trouble? Um, no. I have barely even tracked regression, much less got around to a useful investigation of what in r66004 caused the regression. I usually have a build tree around and can do the typing if you tell what dump-file or somesuch you want? (Though I'm not sure that it's just the single test-file; I should verify that first.) While I'm here, let me log recent results. Not getting better. :-( r231343: 42688158156
GCC 6.1 has been released.
GCC 6.2 is being released, adjusting target milestone.
GCC 6.3 is being released, adjusting target milestone.
GCC 6.4 is being released, adjusting target milestone.
GCC 6 branch is being closed
The GCC 7 branch is being closed, re-targeting to GCC 8.4.
GCC 8.4.0 has been released, adjusting target milestone.
GCC 8 branch is being closed.
GCC 9.4 is being released, retargeting bugs to GCC 9.5.
GCC 9 branch is being closed
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
GCC 10 branch is being closed.
GCC 11 branch is being closed.