https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97623
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Wilson Snyder from comment #7) > Thanks for the quick service. I can't easily try GCC trunk, but: > > -O2 > compile 98.61s > runtime 25.76s > > -O2 -fno-code-hoisting > compile 40.13s > runtime 26.40s (+2.5%) Hmm, OK. Can you provide the output of -O2 -fno-code-hoisting -ftime-report? I have a patch limiting hoist insertions to 3 and that makes the reduced testcase drop from 13s to 2.5s and drop PRE into reasonable territory: tree PRE : 0.44 ( 18%) 0.00 ( 0%) 0.45 ( 18%) 1177k ( 5%) and with -fno-code-hoisting tree PRE : 0.37 ( 15%) 0.00 ( 0%) 0.38 ( 15%) 477k ( 2%) where it takes only two insert iterations (the last iteration is always a no-op, so that's perfect). Before limiting but after the already committed patch it was tree PRE : 10.41 ( 81%) 0.01 ( 33%) 10.48 ( 81%) 11M ( 33%) The function is quite big and ANTIC_IN compute is costly and more importantly AVAIL_OUT is quadratic in size (ugh). > -Os > compile 4.25s > runtime 23.42s (-10%) > > That -Os runs faster is expected as this program is generally > instruction-fetch limited. I'd have expected -fno-code-hoisting to help > more, compile time wise. Me, too. > Am I correct in understanding that the slowdown is roughly correlated to the > number of "if" or "?:" statements? Yeah, that's the case.
